MuseScore first engraving impressions: Part 2

• Jul 1, 2020 - 11:44

[What's all this about? see @Tantacrul's post from earlier today - also Part 1 (and the bigger overall post that also explains what this is about) will appear at some point, it's in moderation hell]

Continuing the exploration of MuseScore's features, and the current state of its default engraving quality, today I set a page of dense late-Romantic piano music, which highlights different issues from orchestral music (which generally is made of single lines, even if there are a lot of them). I chose a page from the first movement cadenza of Nikolai Medtner's Piano Concerto No 2, which I've been learning recently. Here's the original page, engraved by F. M. Geidel, Leipzig and published by Zimmermann in 1928:
I wasn't trying to match an existing style exactly this time, though I wanted to broadly replicate the details of where the symbols were placed and so on. I changed the music font to Bravura and text to New Century Schoolbook, but otherwise left most of the styles at their defaults.

I noticed that when creating a score, the first system is not indented. This suited me fine here as I was setting a single page from the middle of a piece, but in general I the first system of any piece/movement should be intended even when there are no instrument labels. A small thing, but it would make the default output look more professional.

This is a challenging page from an engraving point of view, in all sorts of ways. Here is my attempt:
And here are some engraving issues I encountered.

Stem lengths

This is a big one, and it's bound up with the issue of beam placement which is definitely a major area that needs a lot of attention. If we consider the lower voice here, it's clear that the currently coded rules for stem lengths are creating an erratic result:
2a stems.png
Yes, stems should be shortened when they extend outside the stave, but this shortening needs to be limited; it also looks like the presence of flags prevents this shortening from happening.

A beaming issue that's not apparent in the final page, but I noticed during input: where a beam goes over a rest, in general the rest should be vertically displaced rather than the beam. For example:
2b beamoffset.png


I think MuseScore's accidental placement is generally pretty good (I've seen much worse), and this page has some nasty challenges in this regard, but there is room for improvement. While I understand the desire to have accidentals an octave apart aligned, this rule can be relaxed where it will prevent large unnecessary spaces between the accidentals and the notes, as in these two examples:
2c1 accidentals1.png 2c2 accidentals2.png
Something I noticed during input is that where there's an accidental on a shared notehead (i.e. a unison between two different voices) the accidental is repeated:
2d two-voice accidentals.png
I can fix this by hiding one of the accidentals after it's input, but this seems like a poor implementation to me: if the noteheads overlap then the accidentals should collapse too. This is actually an error, since it looks like a double flat.

Another thing I noticed, which is more of an implementation issue than an engraving one per se, is that accidentals are considered to persist on their pitch (and in the same octave) over clef changes. I noticed this here:
2e accidentals.png
where the A after the treble clef was played back as an A natural. I can see the argument for this, but from a performer's point of view this is horribly ambiguous, and the second A needs an accidental regardless of what the policy is. In some ways this is similar to the issue that arises when an ottava mark begins or ends in the middle of the bar: the question is then, do accidentals apply to the octave where that pitch sounds or the one where it's written (regardless of whether it's within an 8va or not). There's a nasty instance of this in the cadenza to the Rachmaninov 3rd Concerto:
2f rach3.png
Is the highlighted note A flat or A natural? (the left hand harmony underneath is Bb7, but both options sound totally plausible. For the curious, from looking elsewhere it in the piece it seems that the accidentals apply to the sounding octave, which would make this note A flat. I'm not personally convinced, but in any case it's ambiguous and a courtesy accidental (of whatever type) should be provided.)


It would be good to have an option to place the numeral at the rhythmic centre of a tuplet rather than the graphical centre of the bracket or beam, for example:
2g tuplet.png
In that particular instance the question would be moot if the overall spacing were otherwise improved, but that's a separate (and very big) subject.


For some reason setting the anchor to 'above stave' gives a different result (larger offset) than 'above chord'. Is this by design?
2h articulations.png

Grace notes

It seems to be impossible (without extensive faking) to have a clef change within a group of grace notes, or indeed between grace notes and the main note. Also, at least as far as I can tell at first, cross-stave grace notes don't put the beam between the staves, even though this is usually going to be more desirable. Furthermore, it doesn't seem to be possible to have items snap to grace notes, but only to main notes (like the pedal marking here for instance; or, the end of the trill in the final bar of this piece). This can be manually adjusted of course, but there's a risk of those changes being undone/things moving apart.
2i graces.png

Slurs and ties

I mentioned endpoint positioning last time, but a few more details here. One is that we need to ensure space between a note which has a slur ending on it and another beginning:
2j slur-slur.png
and care is needed for ties between inner notes of chords (especially difficult where accidentals are involved, and/or augmentation dots):
2k innerties.png
Ties from small notes (whether grace notes or cue notes or other small ornamental notes) should, at least optionally, be thinned:
2l smallties.png
There's also a problem with the right-hand endpoints here. This might seem like an unusual edge case but it comes up surprisingly often in piano music.


It's very nice that pedal lines automatically vertically align over the system. I wonder if this functionality could be leveraged to dynamics and tempo markings, among other things.

I was pleasantly surprised by how painless it was to create the small-note flourish on the fourth system. However, it would be great if the small notes that coincide with full-sized notes in the other voice were properly aligned:
2m smallnotealign.png

Some thoughts

It's already possible to start thinking about how to prioritise some of the engraving issues to tackle. Some things are low-hanging fruit, not necessarily in the sense that they will be easy, but in that they will make a big difference.

Thinking very broadly, it seems to make sense to think first about matters of layout and page formatting first - the things that are obvious when you see a page at first glance, or even at a distance - and then moving inwards from there to ever finer details. In other words, we want to to be difficult for anyone to dismiss a page of MuseScore output as amateurish or unprofessional at first glance. So firstly:

  • Brackets and braces and system barlines
  • More sophisticated instrument labelling
  • Vertical justification of staves
  • Indentation of initial systems
  • System text

Then moving on to issues which affect the overall appearance of the music on the staves in a significant way:

  • Beam placement/slanting; stem lengths
  • Endpoint placement of slurs and ties
  • A new/improved horizontal spacing algorithm
  • Our very own new music font

And then everything else after that - though those two lists are certainly not exhaustive. An assessment of some of the most popular scores on might be a good way of refining/solidifying the order of these priorities.

I plan to do one more page, from a different type of score, to complete this first 'pass'; I think the three together will give a fairly rounded view of the strengths and weaknesses. Like yesterday, I feel there's a lot to be impressed by, as well as a lot of potential improvement.


In reply to by Jojo-Schmitz

Probably not, the accidental is only "courtesy" if the pitch stays the same without it. If I input a note in that place, MuseScore tells me that note is B-natural. Now I want to change it to B-flat. Pressing the flat button changes the pitch, so it shouldn't be treated like a courtesy accidental internally (even though removal of that accidental yields no change to the pitch from a human's prospective).

Thanks for this analysis, I look forward to the rest and digging in deeper. Just a general observation for now - you might want to collaborate with someone who is very experienced in using MuseScore when engraving pieces as tests, to learn the "tricks" that already exist to solve some of the problems you might encounter. Just as one example, the stem shortening is controlled by style settings so that much is possibly something improved with just a tweak to the defaults. And I suspect the accident-on-unison issue you are seeing comes from having added the accidental incorrectly, as others have pointed out. Not saying we couldn't improve the workflow to make mistakes like this less likely, but still, I'd like to make sure you understand what is already possible.

Oh, one final thought - regarding first-system indent, it's common for classical music, less so for other genres. That's been one reason we don't do it by default, but you can do it easily by adding a horizontal frame. Probably there are ways of handling this more automatically, but it is important to make sure we handle the broad variety of types of music people are using MuseScore for.

In reply to by Marc Sabatella

I quite agree! I did acknowledge in Part 1 (which is, annoyingly, not yet available here) that I was quite aware that any obstacles or shortcomings I came across would, in many cases, have solutions that I just didn't know about. So I'm happy to know that there are easy solutions. Part of the aim of the exercise here was also just to document what issues a first-time user encounters, and what seems easy or difficult. One of the main aims is that everything should be correct (graphically and grammatically) by default, and to be 'wrong' should require definite user intervention, and not happen accidentally. Of course 'right' and 'wrong' mean different things in different genres, as you point out, so it's not a question of determining One Style to Rule Them All, but having a selection of defaults which are also user-customisable. That's already possible in MuseScore, so it's just a question of working out the details and the ways it needs to be extended.

In reply to by oktophonie

Well, there are easy solutions to some of what you point out :-). The beam angle code, as I have mentioned before, really needs to be rewritten practically from scratch. Not that the results are always terrible now, but it's really hard to fix the cases that aren't good without breaking other things because of the crazily complex way this code is structured. The tie and slur endpoints are designed to work well in the most common cases, but there are all sorts of places where they don't. I suspect this is mostly this is a matter of adding code to detect and handle these cases.

With regard to accidentals, one thing we definitely do not make clear is that there are really two types of accidentals: "normal" ones that are handled automatically according to the pitch of the note and key signature, and ones you place there explicitly whether needed or not (e.g., for courtesy accidentals). The toolbar and palettes are really intended for the latter; the only reliable way to create the normal automatic kind is using the up/down arrow keys to change the pitch of the note. We do have some code in place so that the toolbar accidentals are automatically converted to normal accidentals in cases where it seems "obvious" this is the intent (this was added around 2.0 I think), so you can get away with using the toolbar or palettes "most" of the time, but it will bite you if you don't do it "right". So yes, it would be good to rethink how some of this works.

In reply to by Jojo-Schmitz

True, but the point as I see it is producing really good results by default, no manual intervention required. It's a laudable goal, and of course it has a lot to do with why autoplace is a thing. Same with staff brackets and instrument names.

The good news here is that architecturally, this kind of stuff is easy. Once it's decided on the "right" way to handle it, we do the necessary work to create the necessary score elements right then and there when creating the score. For the most part, the underlying support for the elements and their layout already exists. Although for indent, if we chose to do it via a style setting via an automatically-generated frame, I guess that something new (but easy) to add.

Thank you for this! It happens to cover a lot of my gripes with the current engraving abilities in Musescore, at least pertaining to what I am generally working on (piano scores). I suppose it's a bit rude to throw in my own list of things that I noticed could not be done, but these are a couple of limitations that did not come up in this particular example:

  • In line with your remarks about grace notes, there is no way to add an arpeggio mark to a grace note. In fact, there's no way to make a "small" arpeggio at all- even attaching an arpeggio to a small chord produces a default-sized arpeggio.
  • Regarding beams, there's presently no way to allow for a beam to continue across a line break, for scenarios when beaming continues between measures.

I'm really enjoying these analyses :-).

Re accidentals. More strikingly from this picture
2c1 accidentals1.png
is the position of the E5. Shouldn't it be to the left while keeping the F#5 centered? That alone would reduce the perceived space between notes and accidentals.

Attachment Size
2c1 accidentals1.png 10.8 KB

In reply to by oktophonie

Oh I see. That sort of makes sense. I however never heard of a single chord in whole notes split in two imaginary voices, especially in this case where the preceding chords don't have two "musical" voices, but are instead notated as separate voices for each hand. One could also argue that the chord is only one voice. Maybe that's why the original engraver chose to represent both F# to the right (with an imaginary single stem going up). But all I'm saying seems to deviate already from the engraving tests in MuseScore ;-).

è una scrittura densa ma comunque "classica". Le cose si complicano un po' quando, nel mio caso, si ha sempre a che fare con partiture di musica "contemporanea" tipo quella dell'allegato1; qui il difficile è capire come sfruttare al massimo MuseScore. Per fortuna che ora in "Ispettore" c'è "Ordine di impilatura" che, in tante situazioni, dà un grosso aiuto. Speriamo che nelle prossime versioni (4.0) ci siano dei miglioramenti inerenti alla scrittura musicale e non ad altre cose più "giacattolo" (Piano Roll).
Buona musica.

Attachment Size
1.png 163.39 KB
2.png 35.51 KB

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