Engraving improvements in MuseScore 4.0

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
• 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.

While we do preserve as much of the manual customisation of styles and item positions as we can when migrating old scores, we would certainly encourage that you manually reset everything anyway, to see how all the new defaults and redesigned algorithms work in combination (even just as an experiment!). There are so many interrelated aspects to engraving that it is well worth trying this to see the overall picture. For example, many of the spacing and padding defaults have been changed to work well with the overhauled horizontal spacing algorithm, but we will preserve those from existing scores even though they might not make as much sense any more.

This reset can be done quite simply:

• Open the Styles dialog (Format -> Style..., or right-click an empty part of the of score and select 'Style...')
• Select everything (Ctrl+A) and then Format -> Reset shapes and positions (or Ctrl+R); the other 'Reset' options in the Format menu may be of interest, too.

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:

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):

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

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.

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.)

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

Changes to expect

The default placement of all beams, and the length and direction of stems, will all be recalculated. In scores from MuseScore 3.0 or later, 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. (Before 3.0 they were expressed as relative values.) 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

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.

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.

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 and ties will be retained. (Between 4.0 and 4.3, the direction of ties in chords was reset to 'auto'; this is no longer the case in 4.4 and later.)

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:

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:

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:

The 'Local relayout' option on beams has been removed in MuseScore 4. This was sometimes used in the past to regularise the spacing for a single voice/part (though it would not reclaim any wasted space). This workaround is no longer necessary.

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 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:

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

MuseScore 3.6

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:

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:

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.

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:

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.

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.

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.

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.)

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.

'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:

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.