Engraving improvements in MuseScore 4.0

• Mar 29, 2022 - 14:01

NOTE: This document is provisional and will be updated frequently to reflect the state of development of MuseScore 4, and to clarify points made by comments and questions.

Some of the before/after images are also placeholders for now. While they illustrate the general idea, they are not necessarily to be taken as an exact representation of the final result. A few images are missing but will be added shortly.

Eventually a lot of this information will be filtered into the new Handbook.

In MuseScore 4.0 we have made many engraving improvements, some of which will have an effect on the appearance and layout of scores created in earlier versions. These fall into four major categories: beams, slurs and ties, horizontal spacing and page layout, plus a variety miscellaneous issues.

An unavoidable consequence of making these improvements is that it is not possible to open a score from a previous version of MuseScore and have it look identical; this document aims to list all of the changes in detail, so you know what to expect when migrating scores from earlier versions.

Where the algorithms that determine the default positions of an item have changed, it becomes necessary to reset some manual adjustments that may have been made to those items. This is because those adjustments may no longer make sense relative to the new defaults. If we have done our job properly, many of them should not longer be necessary! In brief, the following adjustments will be reset when importing an older score into MuseScore 4.0:

  • Stem lengths
  • Offsets of single-note tremolos
  • Position of endpoints and handles of slurs and ties
  • Directions of ties in chords (but not single note ties, or slurs)
  • Layout stretch

More details about these, and all the other changes to expect besides, can be seen below under the 'changes to expect' heading at the end of each section below.

1. Beams

NOTE: Several beam features are currently incomplete: Cross-staff beams (which are drawn completely incorrectly), feathered beams (not yet reimplemented), grace note beam positions, two-note tremolo positions, and manual beam adjustments.

New beam placement algorithm

Much of the code for positioning beams has been rewritten. The length and direction of stems, and the placement of beams, are now determined according to more logical and rigorous rules. Many of these principles are documented in Ted Ross' book The Art of Music Engraving and Processing which, though very hard to find these days, has long been considered the most comprehensive text on this particular subject. (In Behind Bars, Elaine Gould refers readers to this book if they wish to learn about the intricacies of beam slants and positioning.)

One of the main aims of the algorithm is to avoid what Ross calls wedges, which occur at the intersection of the inside of a stem (at the beginning or end of the beam), the beam itself, and a stave line, when the beams are poorly positioned. (We only concern ourselves with these at the start and end of beams, not in the middle, because then it would be impossible any beam to ever traverse a stave line.) The main rationale for this originally was that, when printed, these would fill in with ink, causing an uneven and possibly unclear appearance. While this is less of a problem with modern printing, the fact remains that, since beams are very common items in notation, removing these wedges greatly cuts down on distracting visual noise on the page.

The following illustrates some of the differences. It can be seen that, in general, beam slants are shallower when the beam is within the stave (to avoid wedges), but also many other inconsistencies from MuseScore 3 have been ironed out:

Beam slants

The way that stems are shortened when they extent outside the stave has also been refined. Previously MuseScore gave inconsistent results, particularly where beamed groups were involved, and sometimes also over-shortened notes with flags.

Two-note tremolos are positioned following the same rules as normal beams. Single-note tremolos are now more consistently placed (at a defined distance inside the stem or innermost beam, and with a minimal padding from the notehead):

Vertical tremolo position

Tremolos on unstemmed chords (whole notes, for example) containing seconds are now horizontally centered on the position where the stem would be:

Tremolos on whole-note chords with seconds

Altered beam settings

In order to have beam placement rules that can be applied consistently, certain limitations have to be placed on the vertical spacing of beams. Previous versions of MuseScore allowed the thickness of the beam, and the distance between beams (which represented the size of the gap, not the actual distance from one beam to the next), to be set to arbitrary values. In MuseScore 4.0 the beam thickness can still be set, but there are only two options for beam distance: standard (0.75sp from one beam to the next) and wide (1sp). The latter option is rarely seen in print but was popular for a while with some publishers in the late 20th century.

Beam spacing options

Previously the distance between beams could be set, as a percentage of the thickness of the beam. For the new beam algorithm to make sense, the distance from one beam to the next must be either 0.75sp (regular) or 1sp (wide), otherwise none of the new rules make any sense. The UI has now been changed to only allow 'regular' or 'wide' options. Beam thickness can still be changed, but the beam distance is then automatically calculated from that so the correct beam distance will result.

A new option is available for straight flags. These are quite commonly encountered in scores up until the mid-19th century, when they were largely replaced by the more familiar 'curly' flag, but then became fashionable again in the mid-20th century for some contemporary works. SMuFL fonts can make these symbols available as stylistic alternates to the normal flags. (Bravura's are more like the 'old' (19th-century) design, and Leland's more like the 'modern' one.)

Straight flags in Leland and Bravura

The length of fractional beams is now correctly scaled on resized staves:

Fractional beam scaling

Changes to expect

The default placement of all beams, and the length and direction of stems, will all be recalculated. Beams with a custom position will retain that position; this is possible because beam positions are expressed as absolute values, not as offsets from an algorithmically-determined starting position. The 'Reset shapes and positions' function can be used to see how the new default would look, for these beams. Custom beam direction is also retained.

The position of single-note tremolos will be recalculated, and manual adjustments made to these will be lost.

The beam distance setting, now removed in MuseScore 4, will be mapped to 'standard' or 'wide' according to whether its value is less than or greater than 75%.

2. Slurs and ties

NOTE: The slur collision avoidance is still a work in progress.

New slur and tie placement algorithm

The default positioning of slurs and ties has been greatly refined. The endpoints of ties will now automatically clear dots, flags, stems, noteheads and stave lines, with even complex chords containing seconds being elegantly handled. The direction of ties is also more intelligently decided when chords contain seconds, or when ties go from a chord to a single note or vice versa.

Ties between chords

The endpoints of slurs are more intelligently placed according to their context (whether they are at a notehead, a stem, a flag, over a beam, or floating at the start or end of a system), and will clear stave lines in the same way as ties. The algorithm for adjusting the slurs to clear collisions with the notes they span has also been made more intelligent.

Slur positioning

Slurs and ties crossing a system break will now end just before the final barline, rather than at the end of the stave, meaning that they will no longer collide with the barline or with any key signatures or time signatures following it. (In fact, this applies to all lines: see Lines crossing systems, below.)

Changes to expect

The default placement of all slurs and ties will be recalculated. Unlike with beams, slurs and ties which have been manually reshaped and repositioned will be reset. Fortunately, many of those manual adjustments will no longer be necessary.

The direction of slurs will be retained, as will the direction of ties to single notes. The direction of chord ties will be reset to 'auto'.

A bizarre piece of logic in MuseScore 3 had slurs that were longer than one whole bar would always appear above the notes, regardless of stem direction. This has been corrected.

3. Horizontal spacing

Improved justification algorithm

The two fundamental changes are that a) the entire system is now justified proportionally (previously each bar was considered separately, which could lead to jarring inconsistencies from bar to bar), and b) the minimum note distance setting is now properly treated as just that - the minimum space two notes can be together. Previously it was being incorporated into the calculations of the proportions for different rhythmic values, which was another source of inconsistent behaviour and wasted space. Its default value is now larger than before; the previous very small value was only necessary to mitigate some of these problems.

In this example it is clear to see how the quarter notes used to be differently spaced from bar to bar, according to the context of each bar; now they are spaced equally:

Horizontal spacing

Another widespread problem was that objects could not generally tuck above/below other items, creating a lot of wasted space; furthermore, space was often created for items when it was not even required on the stave on which those items appear:

Items tucking under other items

For this same reason (among others) polyrhythms, even in simple ratios like 3:2, have historically been very poorly spaced (irregularly, and with a large amount of wasted space) in MuseScore. Now any number of simultaneous polyrhythms can all be spaced smoothly:

Spacing of polyrhythms

The spacing of cross-staff notation is now adjusted (where possible) so that the stems are equally spaced, rather than the noteheads; this gives an optically superior result.

(illustration to follow)

The 'Spacing 'setting (in Style -> Measure) has been renamed 'Spacing curve' and its new default is 1.5. A fuller explanation of how the new spacing routine works, and how it is configured, is to follow.

Minor changes affecting horizontal spacing

(See also Page layout, below.)

Many small changes have been made to the layout and spacing of items that will have small but potentially cumulative effects on horizontal spacing.

The spacing of accidentals in key signatures has been improved. These were generally too close before: a constant value was being used, taking no regard of the shape of the glyphs themselves. Now the bounding box if each symbol is considered (as well as the SMuFL cutout data, where available):

Key signature accidental spacing

Key signatures and time signatures at the very end of a system now have a small amount of padding to the right, rather than ending flush with the end of the stave:

Padding at ends of systems

Invisible time signatures and key signatures no longer cause spacing inconsistencies:

MuseScore 3.6
Invisible time signatures in MuseScore 3

MuseScore 4
Invisible time signatures in MuseScore 4

Augmentation dots are offset rightwards to clear flags, where necessary. Previously some stem lengthening occurred in certain cases to try to mitigate this, but this was usually insufficient and caused inconsistencies, so now the stem length is left unaltered:

Invisible time signatures in MuseScore 4

Grace note ledger lines were previously too long (not properly scaled with the rest of the note). Admittedly, the difference is tiny!

The space between arpeggio lines and accidentals has been reduced, and also now takes into account the shape and position of the accidental, the presence of arrows and brackets, etc. The default vertical endpoints are also adjusted in order to not end exactly on stave lines:

Arpeggio spacing

Changes to expect

Layout stretch will be reset when scores from earlier versions are migrated to MU4.

None of the other changes individually cause seismic variations in layout, but even the smallest thing can, in certain circumstances, completely change the layout of a score. Some increase the amount of space required while others reduce it (the latter generally being preferable, or at least less risky).

4. Page layout

At score creation, where many instruments are added, the stave size will be reduced enough so that all staves can be shown on the first page. This is purely avoid the perplexing situation of a system continuing beyond the bottom of the page (or worse, being bumped to the second page because of the presence of a title frame - and then often not fitting there anyway); the user will most likely want to manually adjust the page layout options thereafter.

Margins, headers and footers

The behaviour of headers and footers has been made more consistent and rationalised. Footer text was previously offset downwards from the bottom of the body of the page into the bottom page margin (unlike header text, which sits at the top of the body of the page). This was, presumably, so that the music would not collide with it. However, this strategy potentially fails as soon as footer text becomes more than one line long (the footer spreads up from its origin point), and also makes its behaviour inconsistent with header text, which sits inside the body of the page.

Footer text is no longer offset by default, so it will not intrude into the margin, but the music on the page will now automatically clear any header or footer text, whatever its height. Text frames at the top of the page will also automatically clear headers, if necessary.

Headers and footers

All systems in a score now have a consistent left origin point, except for the initial system, which has an optional configurable indent. Previously, the staves of each system could start at a different position, depending on the length of the longest instrument label shown on that system, or on which brackets were present, giving an inconsistent 'ragged left' layout. The indentation is now calculated according to the longest label and applied consistently through the score. Here, for example, all four systems now have the same left origin:

Consistent left margins with labels

Where there are no instrument labels, brackets and braces are now positioned in the left margin (the staves will begin precisely at the left margin), as is the policy in most traditionally engraved music.

Consistent left margins with brackets and braces

Connected to this, the correct brace symbol is now selected for each system independently, based on the number of staves shown for the instrument on each system, not on the total number of staves used anywhere for that instrument.

(image to follow)

System objects

MuseScore already had the concept of system markings: items which appear at the top of the system but which apply to all staves and extract to all parts (tempo markings, rehearsal marks, bar numbers, voltas, etc.) What it so far lacked was the ability to duplicate these markings at specified points further down the score, as is customarily done in, for example, orchestral scores (where a second instance appears above the strings), or chamber or choral music with keyboard (where a second instance appears above the keyboard part).

Much of the groundwork for this has now been laid, and by way of a preview, can be tried out by opening certain templates supplied with MuseScore 4 (Classical Orchestra, Symphony Orchestra, SATB + Piano/Organ). In these templates, system markings (except for bar numbers) are defined as being duplicated above the string section, or the piano. Eventually it will be possible to configure which types of markings should appear, and where, for all scores.

System objects

Changes to expect

If instrument labels are present throughout your score, and you have 'Hide empty staves within systems' turned on, the horizontal extent of systems may change. Sometimes a system will have more space than before, sometimes less.

There may be slight differences in vertical justification due to the new header/footer spacing settings.

If there are no instrument labels, systems will have slightly more space, as the brackets and braces will extend into the margin.

A minor fix: the 'last system fill threshold' now applies to the final system before a section break, not just to the very last system in the score. The previous workaround (using a frame) is no longer necessary.

5. Miscellaneous

Dynamics

Dynamics are now rendered using the Musical Symbols font (i.e. Leland, Bravura, etc.), rather than the Musical Text font (Leland Text, Bravura Text, etc.).

The Musical Text font is intended for music symbols that appear in the context of running text; this could be music examples (like single notes or simple rhythms) in an academic book, or in footnotes. The symbols are designed to work at this scale. Dynamics may seem to fit in this category, as they often appear in combination with text (e.g. poco f cresc.) but they are properly considered as musical symbols, which are designed with proportions that match the size of all the notation around them, rather than appearing text they happen to be alongside.

The SMuFL specification gives 20pt as the nominal size for normal-sized notation on a stave, so to retain this proportion, dynamics should be at this size. Since some users use the 'Dynamics' text style for strings that combine dynamic symbols with text, this style now has a default of 10pt (which matches the default size of Expression and Technique text), and the dynamic symbols are sized at double this value. If a Dynamics text item consists only of a single dynamic symbol, but the item has its justification overridden to 'left', this will be removed.

SMuFL also allows for the provision of metadata that specifies the optical centre of dynamics symbols, which enables them to be centred on noteheads in a more sophisticated manner than simply using the bounding box (which can give results that look slightly off-centre, given the stylised italic nature of dynamics). MuseScore will now use this data, where it is provided. The exact placement of the dynamics relative to the noteheads will vary from font to font, and is an aspect of each font's design.

Optical centering of dynamics

Metronome marks

Notehead symbols for metronome marks use the Musical Text font (as before), but now are sized in a 5:3 ratio relative to the text string in which they appear (i.e. they will be 20pt in a 12pt text string). The metronome mark symbols in Leland Text itself have been resized from the version included with MuseScore 3.6 (they were previously too large, but 'looked right'; conversely, those in other fonts such as Bravura would have looked too small, but now these symbols should look right in all SMuFL fonts - except for MuseJazz Text which requires an update).

(image to follow)

Lines

Lines at the end of a system now stop before the final barline, rather than continuing to the end of the stave and thereby colliding with the barline and any key signatures or time signatures that follow. (This also applies to slurs and ties; see above.)

Lines over system breaks

Lyrics extension lines in lyrics are now omitted if they are very short (less than 1sp).

Tuplets

The automatic placement of nested tuplets has now been fixed. Previously, an outer tuplet would cause autoplace to ignore inner tuplets and collisions would result. Additionally, an obscure bug would cause the numeral of an outer tuplet to become small if each of the outer tuplet's units were themselves tuplets.

Nested tuplets

'Auto' bracket mode is now more intelligent: tuplets as part of a beamed group will receive a bracket, except where they are simple and have their own secondary beam:

Automatic tuplet bracketing

Changes to expect

Some style settings have updated defaults in MuseScore 4. A full list is being maintained on the MuseScore GitHub wiki. In general, the style settings of an existing score will be preserved as far as possible during the migration process.

One exception is that the 'Dynamics' text style will be set to 10pt (the previous default was 11pt), which now matches the default for Expression text, and dynamics symbols will now be taken from the Musical Symbols font rather than the Musical Text font. The This may mean dynamics appear different in size, but the difference will be very slight. In the rare situation that the Musical Symbols and Musical Text font were from different families, this does mean that the design of the dynamics will change accordingly.

Dynamics will also now be centered optically on the noteheads to which they are attached, assuming that the SMuFL metadata is present for the font being used. Again, these changes will be slight. To better illustrate this change, dynamics symbols which have a local override to their justification will have it removed; dynamic symbols which are combined with text (e.g. "pp cresc.") will not be affected, however.


Comments

This is all fantastic stuff! Thanks to oktophonie and everyone involved in implementing all this! Tons of little (and not so little) things that really add up to a really big improvement overall. Will be interesting to see if it's enough to impress the MET (Music Engraving Tips) folks or not, but it certainly should be :-)

In reply to by Marc Sabatella

To hazard a guess, I expect the following response on MET in general:

  • MuseScore users will be thrilled (with minor quibbles here and there)
  • Hardcore engraving people at MET will politely welcome (or at least acknowledge) the improvements and will allude to (and perhaps point out) areas still in need of improvement
  • Goalposts for MuseScore will start to shift from better engraving to more configurability/flexibility via global settings.

This is of course my general expectation. There may likely be individuals who won't fit into any of these prediction-boxes.

Automatic beam angle reduction. Anti-wedge technology! Wonderful!!!

The before-and-after example looks really good.

I've spent a ridiculous amount of time manually reducing MuseScore's beam angles—largely for anti-wedge purposes, and because unnecessarily steep angles look unattractive to me.

MuseScore 3.6.2 lacked Style settings for beams. I hope MuseScore 4 will offer some, particularly for beams that display above and below the staff.

scorster

In reply to by scorster

Glad you like! It would be good to know what style settings you feel are lacking in particular. The beams have been rethought from first principles so there is a lot of flexibility in the system, but the question, as always, is what aspects of the configuration to expose, and how.

In reply to by oktophonie

Many thanks for all these splendid improvements!
About beams: in Msc 3.6.2. Using Windows I made macros in AutoHotkey to set 'Grow left/right' to 1.08, 1.16 or 1.25 to cater for situations with four beams and to ensure both ends of all beams are attached to stave-lines. See Gould, Behind Bars page 18 and 21. Will the new mapping to 'standard' or 'wide' have the same results?

In reply to by MichLeon

This is actually now done automatically in very limited circumstances for 32nd-note beams. Here the first beam is very slightly widened for the reason you mention:

32nd-note-beams.png

In general, for this reason (and for avoiding wedges) when there are 3+ beams within the stave they will generally be flat by default, as it's then up to the user how to handle it. The starting placement will be one where all beams are attached to stave lines, with the rare exception that for 4+ beams (when flat) it's possible sometimes for one of the inner beams to float in a stave space. If you want to make adjustments in the same way as you've been doing so far, that will still be possible - except that the feathered beam options (which include the 'Grow left/right') are not working in the alpha release, but will reappear soon.

'Wide' beams are actually more flexible, since the distance from beam to beam is 1 stave space, e.g.:

64th-note-beams.png

I have a pixel-ruler installed on my PC for the sole purpose of measuring the horizontal note-spacing in order to correct it. Maybe I'll keep it installed until MS4 is released. Or maybe I'll uninstall it now and stop correcting my MS3-scores' horizontal spacing, and just port them all over to MS4 once released. Either way, thank you so much for fixing the spacing and for all the other small and dramatic engraving imrovements! Really psyched to see all of this in the final release! :) :) :)

Some great stuff in there, I knew there were a few tweaks here and there that were needed but they are some pretty significant improvements! Guessing it meant redoing all the visual unit tests too, would test anyone's patience!

Oh man, I'm just imagining the amount of potential time saved just fixing slurs alone (and before never really getting it quite right, and often settling for good enough.)

Wow, these are a lot of things to look forwards to! Thank you for all the hard work!
In so many cases, these are issues that I have--to the best of my ability and Musescore's capacity--tried manually--and I may add, laboriously--to correct!
So, I should expect some of the scores to look all wonky when I open the files in MS4? Lucky, my opera omnia is not so vast that I won't be able to (re-)clean them up on a case by case basis:-)
Thank you, again
-- WF

In reply to by wfazekas1

There will be differences, certainly (which I've tried to list and explain in this document) though hopefully they won't be too wonky! The settings and layout of the original file are honoured where possible.

It's also easy to reset any scores to new defaults (reset all styles, reset shapes and positions, remove system breaks and so on), then you could perhaps make a new 'house style' style sheet for MuseScore 4 to apply and tidy up scores from there. Of course, if you want scores to look identical to how they did before, you can keep them in MuseScore 3.6 (or earlier) too.

About score layout in general: it should now be easier to fit more music into less space elegantly, especially once the horizontal spacing changes are completed (there is a big chunk more of that still to come) and documented. MuseScore previously wasted a lot of horizontal space, which meant having to spend a lot of time trying to reclaim it or compress things to get them to fit (or, just accepting a lumpy layout). That should be a thing of the past. So, when the time comes, reassessing the layout of your scores (in the sense of where the system/page breaks are) and understanding the spacing settings would be my no. 1 recommendation.

In reply to by oktophonie

"House style"--I kinda like that; it makes it sound like I'm using real engraving software--Oh, wait, I am!

Joking aside, since the release of 3.6, I had considered putting together a "house style" .mss file, and then retro-fitting to the scores which I've done in the last three years or so, just to ensure consistency. But now, it sounds like I should wait for a stable release of 4.0. And thank you for your advice in the third paragraph.

In reply to by Miguel Vicente…

There is a reason (complex and laborious to explain), basically arising from the fact that notes with no beam can have their stems shortened in a linear fashion (once the stems extend out of the stave past a certain amount, shorten by 0.25sp, and then an extra 0.25sp for each scale step, up to a certain limit) whereas for 8th notes it's not quite so simple, as some adjustments are made for beams falling on or around the outermost stave line for various graphical reasons.

Regardless, the discrepancy that arises is not very desirable. I think the solution here is to start the shortening of unbeamed notes sooner (the first 0.25sp of shortening will apply once the stem extends 1sp outside the stave); quarters and eighths on the middle line will then have stems of the same length. There will still be a 0.25sp discrepancy with notes on the second-bottom space (with stems up) or second-top space (with stems down), but that's pretty much unavoidable (and is also the same as in MU3 etc). We will try this presently.

Do you still have an unanswered question? Please log in first to post your question.