MuseScore first engraving impressions: Part 3

• Jul 1, 2020 - 12:02

Today's engraving challenge is a page from near the end of Strauss' opera Daphne, published in 1938:
MuseScore maybe isn't used predominantly for this kind of big orchestral music, but there's no reason why it can't do it. This is a different challenge from the previous two pages I've done. There are lots of staves, and the page is rather dense, though the music on each stave isn't very complex. One thing MuseScore does lack is sophisticated handling of instrument labels, so I've approximated those here. Here's my rough attempt:
My thoughts this time are a bit more general than last time.

Firstly, I used, again, Bravura and New Century Schoolbook. I think this is the single best thing that can be done already to make scores looks better. Emmentaler is not hideous - and actually comes across better at small stave sizes like here, I think - but there are some pretty questionable things in it (like the weird natural sign), and I think it lacks a bit of weight. FreeSerif is also too light, and the letterspacing is dodgy. (I use New Century Schoolbook as I'm used to it from Boosey & Hawkes, but it's actually an excellent font to use with music notation. Other decent fonts are available!)

There are other style defaults that could be changed which would give better looking scores with next to no effort. (I'm aware that style is all a matter of opinion; but by 'better' I mean not just what I like, but also what is much more common in printed music.) For example, I think the vertical offsets of dynamics are too big - excessive space around things is basically a hallmark of poor-quality engraving - and some text style choices are a little odd, e.g. bar numbers not being italic. I have not done a comprehensive survey of all the options yet, though.

Here are some things I noticed this time: some big, some small. In no particular order:

Key signatures

I find the distance between accidentals slightly too small. Not the end of the world, but I also couldn't find any way to modify this. The problem is worse with Emmentaler which has a chunkier sharp glyph.
3a key-signatures.png


There are different opinions over what to do with notes which have an accidental and are tied over to a new system. I'm a firm believer in the policy of the accidental appearing on the note at the start of the new system (even though it's tied), and definitely not bracketed (which is meaningless graphical noise and causes difficulties with tie placement and spacing). This can be applied manually, as I've done here, but it might be nice if MuseScore implemented this behaviour by default.
3b new-system-accidental.png
One possible argument against this is that, where there is only a tie and not a slur (i.e. not like here) it might be ambiguous whether the pitch changes on the downbeat or not, i.e. if the tie is interpreted as a slur. I feel the benefits outweigh that risk here, but regardless of that, where it is a slur to a new pitch on the downbeat of a new system, the slur should not be flat, to be unambiguous:
3c new-system-slur.png

Trills and grace notes

I don't see any way to add accidentals to trills, nor auxiliary notes; the workaround I've seen described is gruesome. I'd consider this a fairly important feature to add for any serious work. (The method used in the original score of the Strauss, with the accidentals in the stave at the relevant position, is pretty unusual! I've only seen it in this and a few of the other Strauss operas. Normally one expects an accidental above/after the tr symbol, or a bracketed notehead.)

Not being able to attach items to grace notes seems an oversight; in particular, I wanted to make sure the ends of trill wiggles could attach so that it would end in the right place. I couldn't see an option to add/remove a slash from a grace note after it was input; and slurs need to be able to automatically clear grace notes:
3d trill.png


When converting a pair of quavers to a tremolo, the stem direction of the pair that the original beam determined was seemingly forgotten, and in one case this caused the notes to have different stem directions, resulting in this mess:
3e tremolo-stem-direction.png
Manually fixable, but it shouldn't need to be. Tremolos should determine the stem direction of notes they are attached to in the same way as normal beams.

In my opinion the thickness and spacing of two-note tremolo beams should match that of normal beams; but that's part of a larger discussion on beam style.


It's very nice being able to justify text items left/centre/right. For text items which are attached to a note (or indeed most other types of item on a stave) I'd argue that centering should really centre it on the middle of the item, not on the x-origin. This is basically the same as how lyrics work - and furthermore, optically it looks best if punctuation at the end is ignored in the calculation, just as already (happily) happens with lyrics in MuseScore. Maybe there could be options for both 'centre on origin' and 'centre on notehead'. Here's a normally-centred 'pizz.' with a lyric 'pizz.' underneath for comparison:
3f pizz.png


Gradual dynamics (cresc. and dim. followed by a dotted line here, though it also applies to hairpins) which have an end dynamic on a downbeat should stop before the barline:
3g dotted-lines.png
An exception could be made for where there is a large distance before the furst note in the bar (if there is a group of grace notes, or a key signature change or similar).

The dash space needs to have a higher upper limit - I have it at 20 here but would like it even larger. It is also problematic that this cannot be set as a style for all such lines - I had to change it for all cresc. lines on this page, which is fine, but unmanageable for a large project. However, a better solution might be to take a cue from lyrics again and have the dashes justified between the start and endpoints. An ideal distance between dashes could be set as well as an acceptable tolerance either side. Since the code for this already exists (at least in part) somewhere, this shoudn't be too difficult.

An important point that's relevant to dynamics here, but more generally to items of all sorts: it is inhibiting for serious engraving to not be able to attach items to any rhythmic position, even when there are no notes or rests there. This is difficult even in SCORE, but there is at least the advantage there that major reformatting/respacing is less likely to happen and therefore items are less likely to end up moving around. In my setting of the Strauss I left out the crescendi in e.g. the bassoons for this reason. Having this same functionality would also be useful for correct positioning of tuplet brackets where the last unit is not physically present (for instance a quaver-crotchet triplet)., and for many other things. Dynamics are maybe the most common.


This music highlights some of the deficiencies in the current spacing algorithm. Space required for items on one stave should not affect items on another unless necessary, but we can see (for example) that the septuplet in the second bar in Flute III is distorted by notes on the second quaver of the bar (in Cl. I etc) and on the fourth semiquaver (in Fl. 1 etc). Here's an example of the spacing from SCORE of a skeleton version of these bars (notes only, from 5 wind instruments and viola):
3h daphne.png


Many of the points discussed in previous days still apply here - slur and tie andpoints is a big one, for instance; I'm also realising that many of the engraving requests I have now are effectively larger feature requests, or require extra functionality underpinning them. This particular exercise did highlight some new issues, but mostly reinforced the impressions previously gained. My rough prioritisation of issues from yesterday remains the same, though different types of score will suffer from certain issues than others. Thus it is worth thinking about what scores already exist on, as well the kinds of scores we might hope people will be making in the future.

Comments welcome, as always!


I'm no expert, but I don't think I can agree on making an accidental appear even if the note's tied and on a different system by default. If I see an accidental on that note, I would generally think it's a different pitch, which could result in my rather careless performance of repeating that note instead of making it one long note. I admit I myself share the blame too, but if the pitch is changed, there'd most likely be a (perhaps courtesy) accidental on the last note. If it doesn't have an accidental, it can be easily treated as one of a pair of tied notes that don't need to be played repeatedly, which is what you expect if you write a tie.

In reply to by Howard-C

It would certainly be optional. I prefer it personally, and it's a common style these days, but isn't used everywhere (and was less common the further back you go). Admittedly it's more useful in orchestral scores (as opposed to piano music, say) where system breaks are also often page breaks, and you end up having to flip back to find out what pitch is intended, where the accidental is missing from the new page.

There is some currently existing functionality to help with that septuplet—check the box for "Local relayout" in the Inspector with the beam selected.

I should preface my remarks on accidentals by observing that I largely implemented the "stacking" algorithm for MuseScore 2, after Daniel Spreadbury posted a wonderful blog article on the subject during the early days of Dorico development.

In your previous post you mentioned exceptions to the octave rule, we can definitely talk more about how that might go and code it up, shouldn't be too hard. Except, this was some of the first code I wrote for MuseScore, and while luckily I added a fair number of comments to help whomever might end up needing to maintain that code, it's still a lot of code to digest or re-learn.

Anyhow, one of the things I hit upon was the idea that accidentals can potentially overlap slightly - they aren't rectangles. But SMuFL didn't have any way to tell us by how much they can overlap. So, we proposed it to Daniel, and now there is the "cutout" metadata, which we use to good effect when building chords (it's one of the places where we can, or could at the time anyhow, point to our defaults as being better than anyone else's). For key signatures, though, we don't use any of that, we just sort of arbitrarily pick some spacing that we thought worked with Emmentaler. Probably this could just be a style setting, and then one that changes automatically depending on which font you are using.

Repeating accidentals on ties by default comes up from time to time. We actually started to try to implement that but it turns out to be trickier than you might think, because deciding whether or not display an accidental depending on whether it starts a system is "too late" - we kind of want to know if the accidental will be there or not when calculating the width of the measure to decide if it first on the previous system or not. I'm sure it's solvable somehow, but anyhow, it probably would have been done by now if it were easy.

I'm not really following your comments about spacing one one staff not affecting that on others. I don't see how that can be avoided, and I see examples of it all over the place in your SCORE sample (eg, the very wide dotted eighth-sixteenth in the second bar top staff, the uneven eighths in the same measure on the third and fourth staves, etc. So I'm not really sure what you mean specifically? I guess maybe you are referring to the fact that the septuplet on the second staff at least gets to be evenly spaced, and as mentioned, we can do that via the "local relayout" option, but that's nowhere near the same as saying spacing is independent from staff to staff. So finding a way to better explain what this really means would be helpful.

In reply to by Marc Sabatella

Re. spacing, obviously I don't mean that all staves should be spaced independently, but space should not be created on a stave by something on another stave where it is not necessary. So the septuplet requires a certain amount of space, and obviously creates space everywhere else since we need to align with it, but then things which are moving within it on other staves should not create any extra space within the septuplet, as happens because of notes on the third and fourth 16ths of the beat.

The local relayout feature is really nice and I can imagine it being super useful in many situations. Here it's really a cheat though, because though it lets us get the septuplet evenly spaced, the beat overall is too widely spaced to start with, because of the unnecessary space that was added.

Bravo for the work on accidentals by the way! That's a big challenge (rarely solved well in the past) and I didn't find anything major to complain about or that I felt the need to tweak - the things I mentioned were really just niceties that might be nice to have available as options.

In reply to by oktophonie

OK, I think I am getting it, the fact that the notes don't line causes an unnecessary gap in one or the other or both, so even with local relayout, there is extra space. I think I have a pretty good idea of how that ends up happening and what's involved in overcoming it. We actually have quite a lot in place to avoid that sort of thing in general, but we do special case some things about note spacing that we will probably want to reconsider.

BTW, the other drawback of local relayout is that it only works on beamed notes, and there are some cases where you can see the effects on quarter notes etc. but can't do anything about it except manually.

Thanks for the comments on the accidental stacking, and we all owe a debt to Daniel Spreadbury on that too :-)

For trills with accidentals, I just put a text with the accidental and adjusted it to be above the trill. As for playback, I put an invisible note with the accidental so that accidental registers in the bar. That might be the gruesome workaround that you mentioned, though I find it doable for a few trills. Could probably put an option in the Inspector to add an accidental (and maybe combine trills with and without a wavy line to just be a toggle for line visibility like with cresc. and decresc.?).
I also found an image that seems to provide an alternate notation (see attached image). I like the clarity but I don't think MuseScore supports that "shifted small note" notation which I've also seen used to specify artificial harmonics on strings.
You have some insane attention to detail on your thoughts on notation; stuff I'd never think about despite having transcribed several large contemporary wind ensemble works for fun.

Attachment Size
fin-tril-ex1.png 3.87 KB

I basically agree with everything you say. I'm glad I'm not the only one who dislikes (in my case, despises!) the FreeSerif font and can't really imagine what were the circumstances/reasons that made the MuseScore team to make it default. I saw somewhere that the style setup will eventually allow to change the text font, but it would be nice to reconsider a better default text font in the first place. Century Schoolbook is also my font of choice (I managed to change the style file manually after intensively browsing the forum) and I'm sure there are other "free" and yet typographically more cared fonts available.

In reply to by m.r-botero

FWIW, the decision was not primarily aesthetic but practical, and the considerations that applied then would would continue to apply now. As I recall, the font had to be something that can be included with the program to guarantee cross-platform compatibility, thus has to be compatible with our open source licensing. Also, it had to contain a relatively full set of Unicode that supports all the languages we do as well as all the various other symbols that might be required for any graphically-oriented program, and it had to be possible within the terms of the license to extend it as necessary to add or replace symbols (particularly the musical ones) for compatibility with how notation programs need to use them.

Back when FreeSerif was chosen, there probably weren't as many fonts that ticked all these boxes as there are now. So it's totally reasonable to consider alternatives. But even so, probably only a small subset of the fonts you might prefer purely on an aesthetic basis could actually be used as the default, for these practical reasons.

I've been reading through your impressions with great interest, and here are a few thoughts:

"MuseScore maybe isn't used predominantly for this kind of big orchestral music, but there's no reason why it can't do it. "
I couldn't agree more! Just because one isn't likely to compose/notate/engrave a late Richard Strauss opera using MuseScore, doesn't mean one shouldn't be ABLE to do it. Such is the nature of "completeness" ! (I use that in a mathematical sense.)

MuseScore's inflexibility with Instrument/part labels is frustrating even in simple scores: even a designation like "Keyboard (for rehearsal only)" can present a problem!

One of the big drawbacks for creating orchestral scores, in my opinion, is the inability to alter staff size within a score. I doubt that Fürstner's edition of Daphne uses the same scaling throughout. Of course, this could be remedied by creating each page as an individual file (is this how it is handled in SCORE?), but that would make it useless as a compositional tool.

It doesn't occur in this example, but you've mentioned the inappropriate size of the note in a tempo marking. Like many, I agree. This can be adjusted on a case-by-case basis, which presents little problem in a simple score--unless I forget to do it!--much more so on one by Elliott Carter. (see "completeness," above.)

Finally, and most generally, MuseScore has a wide variety of users, from beginning students through professional musicians, working in a wide range of genres and styles. (see "completeness," above.) A balance needs to made between defaults and the flexibilty which comes with simple and clear methods of adjusting style parameters.

I am old enough to have come to age in the days of pencil-and-paper standards for compostion, and before the days of computer engraving, so I raise an eyebrow over too many defaults which do the dirty work for you. Unfortunately, I know nothing about coding, so i am good at making criticism and pointing out problems, but useless at helping solve them.

I hope this helps.
-- Bill

I just stumbled across this thanks to a new comment. I'll say agree with most of what you say except that MuseScore maybe isn't used predominantly for this kind of big orchestral music. Symphonic music in general is what I put into MuseScore the most. Both what I write myself and more so what I transcribe. By shear numbers I'm sure piano music is #1 and guitar is probably a distant second but people put the music they like into MuseScore. When it's easy to enter a score such as this, it will translate into better scores that are any subset of this (mostly) so looking at this is a great way to see where improvement can be made in MuseScore. I haven't yet looked at the previous installments and I'm not sure if there are more. I'll read the other with interest.

Many of the text issues you point out are things I'm constantly adjusting or set as a style in my own system.

Tremolos are one of the things that really bother me especially converting beamed notes to tremolos and getting wild beam directions. In my opinion, the tremolos should have all the properties of a beam, with OOP this should have been the case all along, so in the unusual case where your sample tremolos are appropriate, it will be simple to create such a display, using the same techniques used in beamed notes.

By the way, you can add an accidental to a trill line using accidentals in the palette only but they do not affect playback.

The ability to toggle the slash through grace notes would be very welcomed.

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