MuseScore 3.5 engraving report

(If you're wondering what this is all about, see this post!)

Background

My engraving experience started around 1995 with Acorn RISC OS Sibelius; shortly after that I started working professionally for Boosey & Hawkes, and the experience of doing my first score in Sibelius convinced me that it was not really suitable for publication-quality work at that level (not that this stopped many publishers at the time!); shortly thereafter I switched over to using SCORE, the quality of the output of which had long been an inspiration to me, and I used it ever since.

The strength of SCORE lies in its flexibility; you can change (almost) any aspect of the notation in whatever way you like, even if it results in something that makes no musical sense. This is completely invaluable for handling any kind of unusual or advanced notation. I have often characterised SCORE as a graphics program that happens to know a bit about music; it does not force you into working a certain way.

The downside is that nothing is automatic; if you move a beam the length of the stems underneath does not change (unless you tell them to); conversely, if you change the stem length of a beamed note, the beam does not adjust automatically. Working in SCORE is very 'low level'; like programming in C as oppposed to something like Python. Nevertheless, its flexibility and power (and extensibility: the simple file format and modelling of data mean that it's very easy to write tools to help with all kinds of tasks; some users have written very powerful tools which act as extensions of the program. I've even written a few myself.) And the possible quality of its graphical output is why it is still used extensively today.

In the past few months I started using Dorico, having had a copy sitting around for a couple of years. It is a totally different experience from SCORE; for one thing, it can function as a composition/arranging/playback tool (SCORE is really an engraving tool only, concerned with the visual appearance of a printed page and nothing else). I used it for making some quick arrangements of music, transpositions of some songs, and a score of a chamber piece from a set of parts. All of these things would have been rather painful and arduous in SCORE, though they are possible.

Dorico, unlike SCORE, does a lot of things for the user, and in particular I was impressed by the lengths it goes to ensure that after basic input, the music is grammatically and graphically correct. That is to say, rhythmic groupings and beaming is right, accidentals including cautionary accidentals are automatically and logically applied (grammar), and items are well spaced, positioned, and collisions are avoided (graphics). This is essential given that the average user often does not know about the rules of notation, or possibly is more interested in actually getting stuff on paper and doesn't care about them; moreover, in my experience as a performer playing in countless composer workshops at universities and music colleges, even otherwise talented and knowledgeable composers have no idea about the subtleties of notation (or the practical importance of getting the details right), and assume that whatever the computer has produced for them automatically will be perfectly adequate.

The holy grail of notation software is that after basic input of all the notes and other items, the resulting score will automatically look perfect with no extra tweaking required (according to built-in and extensively user-customisable preferences). Currently no notation software does this - and SCORE doesn't do it at all, requiring huge amounts of time and expertise, but repaying it handsomely - but Dorico already does a very good job in most situations. There is no reason why MuseScore cannot do just as well - or better.

In assessing the current state of the engraving quality of MuseScore 3.5, I was looking at it from several angles, including:

• How good is the default appearance of music when input? What problems are apparent and how easily can these be fixed manually?
  • When making adjustments, how flexible and powerful are the options? Are there things that cannot be done without painful workarounds?
  • What would be lacking in MuseScore for a user wanting to produce a score professionally for publication by a 'major' publisher?

This report represents a first look at these questions but does not pretend to be exhaustive. A thorough exploration of any of these questions could continue indefinitely, and in any case would be a question of long-term gradual development. The aim was to identify the most important general areas that could then be prioritised.

Process

I spent three days using MuseScore to engrave three different types of score, to assess the strengths and limitations of the engraving currently. This was also my first time using the software, so learning how everything is implemented from a UI point of view was part of this experience.

For each day I wrote up a general report of my findings. The three scores were:

1. A page from Harrison Birtwistle's choral/orchestral work Angel Fighter, which I engraved in SCORE in 2009/2010 for Boosey and Hawkes. Here, as well as being my first exposure to the program, the aim was to see to what extent I could replicate the style and quality of a score I had made myself, without unreasonable amounts of effort. Report: (link to follow)
2. A page of reasonably dense and elaborate solo piano music, in this case part of a cadenza from Medtner's Piano Concerto No 2. The engraving challenge posed by dense, multi-part music on two staves is very different from that of single lines, even when there are many of them, as in an orchestral work. This also provided the challenge of matching the quality of (good) old-school plate engraving. Report: (link to follow)
3. A very dense page of orchestral music, taken from Strauss' opera Daphne. Here the aim primarily is to assess the suitability of MuseScore for handling scores with large numbers of instruments, and the some of the layout problems this throws up - so matters of page layout and scaffolding, alignment of items between staves, instrument handling and so on. Report: (link to follow)

I'd encourage reference to those reports for information on some of the details I found and thoughts I had on the way.

Findings and recommendations

First impressions are important, and when it comes to prioritising issues to tackle, it makes sense to start with those that will make the most immediate impact - especially where the cost of implementation is low. In general this means looking at aspects which affect the layout or overall appearance of the page, or changes which affect the majority of notation items, before worrying about fine graphical details within the music itself. The following list broadly follows this, so can be taken as a first attempt at prioritising the issues that need attention.

Fonts

Some people are no doubt fond of the default music font, Emmentaler. I don't think it's hideous, but it's problematic in quite a few ways. I certainly wouldn't to get rid of it but I think having a better default music font is the easiest single stem to improve the quality of the output. (Conversely, a bad basic symbol set immediately marks a score out as 'amateurish' - even if it's anything but.) Two strategies have been discussed in the design team already:

1. Switching to Bravura as the default, possibly as soon as for the release of 3.5. Steinberg have done a very good job with it (I certainly don't agree with 100% of everything but it's better than any currently available OFL alternative). Some users wont like this - musicians tend to be conservative and object to changes generally, but they can change back to Emmentaler if they really want to. Many, I suspect, don't actually think about the font at all, or particularly care. This effectively gives all new scores a free visual upgrade for almost no effort. Also a new font in v3.5 will perhaps ease the transition towards all of the visual improvements that will come in v4. The community has previously discussed this idea of switching to Bravura and rejected it, not wanting MuseScore to look too much like Dorico. While I take the point, I'd rather the scores just looked better, and Bravura is better.
2. Develop our own font for MuseScore 4 (possibly to be the default), based on the SCORE symbol set. @Tantacrul and I have started work on this already. Scorlatti, by Abraham Lee, is an extant font which is a fairly straight conversion of the SCORE symbols, with a few alterations of his own. I'd propose we do the same thing ourselves. I have my own version of the SCORE symbol set to which I've spent a lot of time over the years making small refinements (for the most part nuances of placement, consistency, positioning) which collectively - in my own humble opinion at least - add up to a significant improvement over the defaults. Having our own font also moves us away from being a 'Dorico clone'. (We don't want to be a SCORE clone either!)

A surprising number of text items are used on a music page: not just titling and instrument labels and tempo markings, but also within the music itself: expression and technical instructions of course, but also e.g. tuplet numbers and fingerings. Therefore changing the text font will also have a big impact on the page. FreeSerif, the current default, is not a beautiful font, and as a Times New Roman analogue, unimaginative too. (From Wikipedia: "Monotype executive Stanley Morison, who commissioned Times New Roman, noted that he hoped that it "has the merit of not looking as if it had been designed by somebody in particular"".) Fonts with a bit more weight tend to work well with music notation; Boosey's default is New Century Schoolbook which works very well (and it's no surprise that the Dorico team chose to do a very good impression of it with Academico); Chronicle Text is an example of a commercial font that would look good. Though we are, of course, limited to free fonts with an appropriate licence, or that we own outright.

Different music fonts will work with different text fonts; so some time could be spent finding good pairings. This can form part of the work on styles.

Styles

Many - even most - engraving questions have no single answer. Often the answer is 'it depends'; just as often, when asked about whether option a or b is better, the answer is "pick either one, it doesn't matter - just be consistent". It is no surprise that managing styles and preferences in music notation software is complicated; this is something else that Dorico has done quite well. (SCORE doesn't help you at all: you just need to be extremely disciplined. But this buys you the ability to easily break free of a style rule in an exceptional case if you need to.) Furthermore, there are differences in style between genres (baroque, classical, romantic, jazz, pop) and even regions (there are distinct features of engraving style in France, Germany, Russia, the UK, the US, etc). MuseScore 4 should, at the very least, provide a number of default preset styles for different types/genres of scores which will ensure elegant and consistent results with little or no further user intervention. This will cover everything from text and music font via bar number placement down to the policy on accidentals and tied notes.

The appearance of default scores could already be improved through overhauling the settings already available in the Style window. Some of the basic offsets are too generous, for example (dynamics and various text items). In conjunction with a change of default font and refining of some text styles, this could make a big difference. Also line thicknesses is an often-overlooked aspect of visual style: different settings will be appropriate for different music fonts, for one thing.

Page layout

The perception of the overall appearance of a page - before we even start thinking about the details of the notation - depends on a number of things.

Staves: size and vertical justification

A newly created score should have an appropriate stave size. These can be pre-set in templates, but if the user selects their own instruments, it would be very nice if a sensible stave size could be suggested for the number of staves involved. That is, if there are a lot of instruments, the stave size should at least be small enough that all the staves can fit; if it's a piano quintet score, it should be possible to get three systems on a page, and so on.

Vertical justification of staves is important. A page should be vertically filled, with the space distributed between staves/systems dynamically. MuseScore has most of the functionality for this already but it could be developed. In particular it needs to be possible to set maximum distances between pairs of staves (e.g. between left and right hand for piano, so they do not stretch too far apart) as well as staves that should have greater spaces (e.g. between instrumental sections in an orchestral score). Our templates would include sensible settings for this. SCORE has quite a good system that I propose I write up to see what can be taken from it.

The pages of a score are ideally formatted such that there is a music block (from the bottom stave line of the lowest stave to the uppermost stave line of the highest) on each page with consistent height and positioning. Exceptions to this should be possible in extreme cases.

I can even imagine a system whereby a template is dynamically generated based on the instruments chosen, the page size, font choices, and maybe other stylistic choices (period, genre, etc). But that's a project.

Instruments: labels, brackets and braces

The lack of automatic bracketing, bracing and barlines through systems is very problematic. This produces a very unprofessional appearance. If we steer the user more towards the templates, where these can be preset, so much the better (again, exactly how bracketing is handled is a stylistic choice to some extent), but where they define their own score by choosing instruments, sensible defaults should be applied. I also think that enforcing a default score order is important: at the moment the instruments are added in whatever order they are chosen, which can result in chaos. The user should not need to know all the details of how to order things conventionally; though they should have the ability to go against the standard if they need to.

Instrument labelling needs an overhaul. This is a complex area which will require a lot of configurability; at the very least, it needs to be possible to split labels into instrument names and numbering. That is, rather than Flute 1 / Flute 2 / Flute 3, we have three staves (bracketed) numbered 1 / 2 / 3, and a single 'Flute' label on the middle stave. As with all these 'page scaffolding' issues, there is a lot of variation here depending on style, publisher, country and so on. Much thought will need to be given for how to handle instruments combining onto a single stave or splitting onto multiple staves during the course of a piece, if that functionality is eventually desired (which it presumably is).

System text

Currently appears only at the top of a system. This will need to appear above the strings as well in an orchestral score, for example (this can also be set in templates), but in general it needs to be possible to have it appear at multiple positions as the tradition/user expects.

System indentation

The initial system of a piece, or a movement, should be automatically indented, even when there are no instrument labels. Not doing this is another 'amateur' giveaway.

Horizontal spacing

Spacing and justification of music is one of the biggest challenges in notation. MuseScore does a good job currently, but much better is possible. In particular, spacing requirements on one stave should not affect the spacing on other staves where it is not necessary.

The spacing abilities of SCORE are renowned. Some of how it works is documented, some other aspects I know from experience, and some more I could deduce through experimentation. I would propose to write up its method as best I can, to assess the feasibility of incorporating it into MuseScore. As well as producing an excellent visual result it is also extremely configurable.

(Despite the brevity of this section, this is definitely a major undertaking.)

Beaming and stem lengths

This is an challenging area where MuseScore does not do particularly well. The community (on Telegram) have also drawn my attention to this already and say that the code is in need of an overhaul, both for readability as well as its functionality. Beam placement is an art rather than a science, and there are different views on what rules to follow. Moreover, as with horizontal spacing, there needs to be a lot of user customisability. However, it is easier to break down into a system of rules. Like the horizontal spacing question, this is a big task, but will make a correspondingly large impact on the visual appearance of scores.

(The handling of tuplet brackets is also closely connected to the question of beams.)

Slurs and ties

Along with beams, the most challenging aspect of notation. There is much that can be improved here (several details I mention in my reports, but not everything). This is actually an area I have some coding experience in as I wrote a quite elaborate script (in Python) to automate positioning of slurs and ties in SCORE. This was not a one-stop solution - manual adjustment was still required afterwards, to some extent - but saved a huge amount of time as well as producing much more consistent results.

The two central problems with slurs and ties are endpoint placement and curvature. The endpoints should avoid colliding with other things (stave lines in particular, but of course notes, dots, other slurs and ties and so on), while remaining clear which notes they connect; curvature of ties should be relatively shallow, though proportional to their length, and the midpoint should also avoid stave lines; curvature of slurs should be sufficient to clear all items they span, though (unhelpfully) with some exceptions. Of the common notational items this is perhaps the most context-dependent. And, as with beams, there are many user preferences to accommodate.

Some good work has been done so far with MuseScore in this area, but a more more thorough specification of rules and robust behaviour is needed.

Notation features

Changing the music font can improve the majority of symbols on the page; staves, brackets and barlines, beams, stems, slurs and ties, which are all drawn around the font symbols, represent the vast majority of everything else on the page. Once the handling of those elements has been improved (and the related matters of spacing and layout), we are down to more localised notation issues. I have already identified some which I think are important to add in order to enable 'publication quality' work. Though I am still a new MuseScore user so there may already be solutions to some of these problems - and there will certainly be others that I have not yet discovered. These are essentially feature requests rather than an assessment of the implementation quality of currently available functionality. And this is nothing like an exhaustive list, just some things that occurred to me in the first few days!

Attachment of items to free rhythmic positions

It should be possible to attach items to any rhythmic position even if there are no actual notes (or rests) at this positions. This example from the Strauss for example:

On the lower stave, the cresc. should be locked to the second crotchet beat, not attached to the dotted minim and offset, such that it might move around if things are respaced, or parts extracted. This is very commonly required. It should not be necessary to use invisible notes or similar workarounds, which would distort the natural spacing if this appears in a different context (again e.g. when parts are extracted).

Here is another example:

The right end of the triplet bracket should be positioned where the third quaver would go. (If there is a third triplet quaver in another part at the same time, it should be clear that it aligns with that. That also means more space will be required.) This means that MuseScore needs some way to determine the position of items that would exist at a certain rhythmic position, without having those items actually affect the spacing in any way.

How to implement a UI for this feature might be an interesting challenge! The simplest method I can imagine is adding the possibility to apply a rhythmic offset to a note, as opposed to (or in addition to) a visual displacement. So in the cresc. example above, the text could be added on the downbeat, and then given a rhythmic offset of +1 crotchet.

Accidentals and auxiliary notes for ornaments

It seems to be impossible to add accidentals to ornaments (frequently required for trills in all music) without painful hacks; this also has implications for playback. There is no mechanism for adding auxiliary notes (bracketed noteheads) either. This is a serious omission.

Grace note handling

I noticed various difficulties with grace notes:

• Items cannot be attached to them
• It is difficult or impossible to add/remote the slash
• Clef changes cannot occur within grace note groups, nor between the grace note(s) and main note
• The 'grace note after' and 'grace note before' options have confusing behaviours (I probably just have to experiment more)
• Cross-stave grace note groups cannot have the beam between the staves

So this is an area which maybe could use some attention.

Intelligent text handling

There are some things I would love to see here - they are possible manually but are tedious, and I also know from long experience that handling all the text items around music can take up a surprising amount of time.

• The ability to centre text on a note. Already we can centre text on its origin position, and left/right justify, but a marking on a note (arco, ten., div., and so on) looks best centred on the midpoint of the notehead, and with the end punctuation not included in the calculation. This is precisely how lyrics already work, so the functionality is there already! Perhaps a 'centre on notehead' option might be added to the already available options, but one which behaves intelligently (i.e. the extent to which the text is offset to the left can have a maximum limit, and also it can be graphically aware so that text is not pushed backwards into barlines, and so on.)
• Intelligent 'stretchy' dotted lines for cresc. - - - and rall. - - - and similar. Again, lyric dashes already do this, so there is extant functionality that can be used elsewhere.

Some miscellaneous thoughts

The existence of the corpus of scores on musescore.com is extremely useful, as it gives us a huge body of data to test any general changes we make to determine shortcomings, find edge cases we haven't considered, or even to alert us that we're going down the wrong road entirely.

All of the above represents a (very ambitious) 'Phase 1'. A theoretical phase 2 involves drilling down into the really fine details of notation and working out optimal ways of handling them so that our solutions are as comprehensive as possible. Eventually that could get us to a place where a user who just doesn't care about any details don't have to - the notation will all look great by default, with no extra intervention.