Improved Note / Accidental Layout In MuseScore 2.0
The most basic feature of a music notation program is note layout and rendering. In MuseScore, layout of notes - including chords, augmentation dots, ties, and accidentals - has not changed appreciably for years. But while MuseScore has always done a good job in the simple cases, there are a number of not uncommon situations where MuseScore made surprisingly poor decisions. This requires the user to adjust things manually - assuming he can even figure out what the correct layout is and how to do the necessary adjustments. For even moderately complex scores (especially piano or guitar music), this could be a time-consuming and error-prone process.
For MuseScore 2.0, the basic layout algorithms have been overhauled over the past few weeks to greatly reduce if not all but eliminate the need for manual adjustment of notes, chords, dots, ties, or accidentals. We used Elaine Gould's "Behind Bars" as our primary reference for what correct layout should look like, although we also consulted other references and published scores.
You can check out the results in any recent nightly build (for testing purposes only; still not ready for "real" use). For scores created in 1.3 or earlier 2.0 builds, you may need to first remove any manual adjustments you had already applied.
Some of the specific improvements are shown below. Note again that in most simple cases, MuseScore already did a good job, but the examples included here are not especially rare or unusual, either.
Handling of seconds in multivoice context
Before: 
Spacing of overlapping chords
Before: 
Dots in multivoice context
Before: 
Length of ties
Before: 
Stacking of accidentals
Before: 
Before: 
Regarding this point specifically, we also owe a debt to Daniel Spreadbury of Steinberg - a company in the process of developing their own notation program - for posting an article on accidental stacking and a comparison between a number of different programs. This came out right at the time we were looking at this ourselves, and it led us to a number of further refinements. You can see his article here , his comparison here (MuseScore 1.3 is "Product E"), and the results obtained by MuseScore 2.0 here .
Vertical position of rests in multivoice context
This one has actually been in place for a long time, but seems worth mentioning here.
Before: 
Finally, here for your consideration is a piano score that was created with no manual adjustments whatsoever. In 1.3, there are over 20 separate sets of manual adjustments that would have been needed to render this score correctly, but with the current 2.0 builds, it is practically perfect right out of the box:
By way of comparison, the 1.3 version is here . See if you can spot all of the places where manual adjustment would have been needed to correct this :-)
| Attachment | Size |
|---|---|
| Mystic Reverie unadjusted.png | 81.87 KB |
Comments
...transforming from spartan functionality towards refined elegance right before our very eyes!
Congrats to all involved...
As someone that has to do a lot of these manual alterations, I'm so glad to see it will be much easier in 2.0. Can't wait for the release.
I am quite impressed on the new accidental placings
It seems you have read http://blog.steinberg.net/2014/03/development-diary-part-six/#comment-1… thoroughly. ;-)
It looks so great! I can't wait to see how awesome the finished 2.0 will be! Congratulations to everybody involved!
This eliminates hours of manual adjustments! Thanks for your efforts.
Wow! Even Finale can't get this right without some really convoluted adjustments. I put the example into Finale 2012, and here are the results:
https://dl.dropboxusercontent.com/u/8126161/FinaleTest.pdf
Some things to notice:
1. It is clear that the accidentals in one voice have no affect on the spacing of the other voices, leading to some really ugly collisions that can only be resolved by either manually spacing (time consuming and awkward) or creating ghost notes and accidentals in a third layer to "force" the spacing to happen as it should.
2. Finale's spacing between accidentals is not as compact as MuseScore 2.0. Man, does MuseScore look so much better in this regard!
3. There appears to be a spacing bug happening in the lower voice of the measure 11 upper staff.
4. Ms. 16 & 19, lower staff: Finale makes a mess of the interwoven voicing here and can't handle the dots in ms. 19.
5. MuseScore's engraving just looks so much nicer than Finale's, IMO.
As someone who writes a lot of multi-voice piano music, I am waiting for this release with baited breath. Wonderful job to everyone involved!
In reply to Better than Finale! by s.chriscollins
Wow, I originally wrote that piece almost 20 years ago (!) when I was using Finale, so I have a Finale version of it too. But I hadn't remembered just how much work it had been to get it looking good. Thanks for taking the time to do this!
BTW, this work isn't *quite* complete. There are a couple of other layout annoyances that I worked on this week and have pull requests for. Hopefully they'll show up in a build soon and I'll post examples. Once that happens, this will complete the list of issues I set out to deal with a month ago when I started working on this.
This is awesome. To me, this is the best feature for the upcoming 2.0 release, even though in a sense it is not really a feature.
One question that hopefully has an answer; I'm certainly not experienced enough in MuseScore to know the answer myself.
Suppose I have a 1.3 score that required many manual adjustments. Now, I would love to allow MuseScore pre-2.0 to recalculate the layout. Is there a simple way to find all the manual adjustments I made? Or to undo them somehow, so I can start with the initial input?
Thanks for any answer to this, but especially thanks for the new algorithm itself. Just what the doctor ordered!
In reply to best new feature for 2.0 by dccarson
select a note head, right click, select all similar, Ctrl-R, repeat the same with an accidental
In reply to best new feature for 2.0 by dccarson
You may have to do flats, sharps, and naturals separately. Might also have to do some fiddling with the Inspector to reset some things. Or there may be an option to do this automatically when opening a score; that isn't settled.
I do need to caution people that we are only talking about basic note layout (including dots, ties, and accidentals, as shown). There will still be no shortage of manual adjustment potentially needed for other markings, particularly text (including dynamics, lyrics, rehearsal marks, etc). Although this too is actually considerably improved with the new text style mechanism. And TonyM implemented a very nice collision avoidance algorithm for chord symbols last year.
In reply to You may have to do flats, by Marc Sabatella
I like the idea of adding an option that automatically resets all manual adjustments. Of course, it would not be the default. And, I think it should only reset things that have been improved upon by the new layout algorithm.
Anyway, thanks for the advice on how to undo my manual adjustments category by category. I'll give that a whirl.
I mentioned above that this work is ongoing. New to builds as of today are two improvements in *vertical* positioning.
Ties and staff lines
In addition to ties previously too short, MuseScore also allowed them to overlap staff lines to the point of being nearly invisible even when otherwise being long enough. For 2.0, ties will no longer overlap staff lines.
Before:
![tie-y-before.png]( "tie-y-before.png")
After:
![tie-y-after.png]( "tie-y-after.png")
Dots with seconds
Rules for whether dots go above or below the line or space containing the notehead are complex, but for 2.0, MuseScore implements Elaine Gould's recommendations from "Behind Bars" are closely as possible.
Before:
![dot-y-before.png]( "dot-y-before.png")
After:
![dot-y-after.png]( "dot-y-after.png")
Thank you for the clarification on the score incompatibility with 1.3 version and 2.0 version.
can you add option to add notes between rows like:
thank you very much!!!
In reply to notes between rows by seangal
Cross-staff beaming already exists in v2. Create the beamed notes in the bass clef. Select the second note and press shift-ctrl-uparrow. The note should jump up into the treble clef.
In reply to Cross-staff beaming already by schepers
I think it works in 1.3 too, see http://musescore.org/en/handbook/cross-staff-beaming
In reply to notes between rows by seangal
This already exists in 1.3 as well. See Cross staff beaming in the Handbook.
I hesitate to say we're "done" - there are always more bugs to fix, always things that can be tweaked. But ever since posting the sample score I used to show off the note/accidental/tie improvements that had been made, I had been nagged by just one thing I still didn't like: the spacing at the beginning of a number of measures (from barline or time signature to first note). MuseScore 2.0 actually provides a number of controls over this initial space, and it also allows accidentals to take up some of that space in certain cases, but the example I posted contains a number of places where this just wasn't working right no matter how you set the controls. For the most part, the problem is too much space, as MuseScore was not allowing the accidentals to be placed there. So the example I posted originally didn't look quite as good as it should have.
After a joint effort, I think we now have addressed those issues. Look at the initial space in measures 5, 7, 8, 10, 12, 13, 15, and 19 and compare to the version I posted before (either the 2.0 or 1.3 version). If you don't like the specific values used by default, these can be configured in your Style settings, but at least the controls work correctly now, and I think the defaults are pretty good.
Will similar improvements be made to layout of articulations and dynamics? I find I rarely have to manually adjust notes, but almost always have to adjust e.g. accents, hairpins, and fermatas.
In reply to Articulation positioning? by nweining
To some extent, yes, things will be better, but maybe not as good as you might hope.
Dynamics have always had a text style setting to control default position but it's never worked; that is fixed. And Werner also made improvements to the defaults themselves. There will also be a style parameter to control the vertical position of hairpins, so they will always align with with dynamics by default. Similarly, voltas and other lines should be placed reasonably by default. And placement of articulations is a bit smarter, particularly when it comes to multivoice music (the articulations will be placed on the stem side - outside the staff). Furthermore, notes will automatcially respace to avoid chord symbol collisions much as they do for lyrics.
However, detecting and avoiding collisons between different types of elements - like between a dynamic and an articulation, or a tempo marking and a chord symbol - is much harder and won't be undertaken. It's technically possible of course, but it would slow MuseScore down quite a lot unless MuseScore's layout algorithms are optimized to not require a full score relayout on every edit. Someday, I hope to see this happen, but it won't be for 2.0.
Dude, in your "Stacking of accidentals" before and after png's, an E natural has changed into an E flat!
Presumably a png mixup, not a bug in the algorithm, but I thought I'd better point it out!
In reply to All natural is best... by MikeN
Good catch! I actually have no idea what caused that; probably I edited the file for some reason between when I took the 1.3 and 2.0 snapshots. But for the record, I checked again, and loading that test file shows a natural both in 1.3 and in 2.0, and if I change it to a flat in 1.3 and re-save, it loads as a flat in 2.0 also. So all is well :-)
Brilliant work.
Sorry to post here (just because ties were mentioned), but could someone remind me if there was an issue on ties colliding with augmentation dots?
Is this something to be dealt with post-2.0?
In reply to Brilliant work. Sorry to post by chen lung
Thanks! It is something we worked hard on.
I am not aware not aware of an logged issue regarding ties and dots, but I am aware that they there are situations where they can be collisons. Also cases where there can be collisions with involving ties between chords that include seconds. And with respect to slurs (which are actually laid out the same as ties in many respects), there are plenty of cases where slurs can collide with the stems of notes. This sort of more sophisticated collision avoidance is definitely a project I have an interest in post-2.0.
Is there a way to automatically repeat accidentials if they only appeared in a different voice in the same line? See the red markings in this example:
The motivation is that I often need to write different voices (actually interpreted by different persons) into the same line to save paper and it is not necessarily evident that accidentals are valid for all voices.
In reply to Is there a way to by herlock
Not automatically, no. It is the sort of thing someone could probbably write a plugin to do, though. Feel free to start a new thread discussiong the idea.