MuseScore 2.0 - A Great Success

I was excited when MuseScore 2.0 was released a few months ago. I’ve been using the program for a couple of years to engrave scores and generate midi output for rendering into digital performances. Some persistent bugs, left unaddressed too long in the 1.x development cycle, meant waiting for 2.0 for the fixes.

In order to see how 2.0 performed, I selected two fearsomely complex piano pieces I wrote a number of years ago. My goal was to see if I could engrave them exactly as notated in the manuscripts, then realize satisfactory audio performances directly from the scores.

The two pieces are musical reflections on the first and second hexagrams of the I Ching (The Book of Changes). The scores can be viewed as PDFs at

    http://www.schaffter.ca/pdf/Ch’ien.pdf
    http://www.schaffter.ca/pdf/Kun.pdf

or on YouTube (along with audio) at

    Ch’ien:
      https://www.youtube.com/watch?v=0MMXN5VdAnY
    Kun:
      https://www.youtube.com/watch?v=qEWPldWLbLs

Overall, I have to say I am very pleased with 2.0. An immediately obvious improvement is the implementation of fully-functional constrained mouse moves and a “snap to grid” option. What a timesaver. No more firing up a screen ruler and slip-sliding things around until they line up. But the best thing about 2.0 is the new “Inspector,” a pane showing nearly every configurable value for a selected object. My test scores needed many, many tweaks (which were expected because of the scores’ complexity). The Inspector made it much easier to effect the changes than the former note-by-note, right-click method implemented in 1.x.

Ch’ien and Kun posed both notational and playback challenges. Playback being a sensitive point with the developers (the party line, oft-repeated, is “MuseScore is a music notation program”), I’ll write about it in another article.

The main notational challenges presented to MuseScore by Ch’ien and Kun were:

 1. a piano grand staff comprised of four staves instead of the usual two
 2. the use of transposing clefs (8va and 8va bassa)
 3. ottava lines
 4. chords joined by the stem across multiple staves
 5. cross-staff beaming
 6. continuing beams over system breaks
 7. arpeggiandi across staves
 8. open-ended ties across bar lines
 9. long slurs with awkward profiles, sometimes spanning staves
10. additive rhythms, meaning no time signature and bars of significantly differing lengths
11. unusual tuplets, e.g. 5-64ths, with brackets
12. multiple grace notes
13. accidentals that apply only to the notes they precede
14. metronome markings given in 16th notes
15. span lines, e.g. Ritardando.....
16. extensive dynamic markings
17. precise pedaling instructions
18. text instructions requiring more than one line

MuseScore 2.0 rose to every challenge, as the finished scores show. Both are perfect in that every item appears exactly the way I want, where I want it. The overall spacing, layout and justification are excellent, as is the design of the musical symbols and notes. In terms of the finished score, MuseScore 2.0 is easily the best WYSIWYG music notation software out there. With continued development, it stands a very good chance of becoming a killer app, as the GIMP is to graphics, or VLC is to media players.

I generally judge the usefulness of a WYSIWYG program by whether it ever leaves users stuck with something they don’t like. A well-designed and implemented program allows for overriding every default, or, at the very least, for coming up with creative ways to improve the undesirable or achieve the unusual using the program’s native tools.

MuseScore is exceptionally well designed in this regard. A good example occurs on pages 11 and 12 of the Ch'ien score, where I needed beams with different values (8th and 16th) in several voices to continue over the system break. MuseScore doesn’t handle this requirement (it’s very rare), and it’s tricky to “fake”, but by hiding various beams/flags and manually drawing lines of the correct thickness and positioning them over the notes, I was able to achieve the effect.

I rank MuseScore’s implementation of “hiding” (making graphical elements invisible) amongst its best-implemented features. The developers have observed the principle of orthogonality, such that one can hide, with respect to any note, the accidental, the notehead, the dot, the stem, the flag and the beam separately. Most users will never need such extreme separability, so kudos to the developers for providing it. Best of all, hiding can be toggled with a simple keyboard shortcut, the letter “v”, and toggling the hiding/showing of all invisibles at once can be mapped in Preferences by the user.

Now, to the specifics.

Items 1-3: I had no problems setting up the four-staff grand staff. Furthermore, on playback, the transposing clefs transposed as expected, as did the ottava lines.

Items 4-6: Stretching stems across staves was accomplished easily by hiding note-flags and beams (if any) and extending the stem from one staff to meet the stem on another.

Cross-staff beaming was straightforward and reliable. A missing feature was the ability to set the beams horizontally automatically; where slanted beams looked awkward, I had to adjust them manually. This required firing up a screen ruler since the beam handles do not snap to the page grid, which would have significantly eased the operation.

The need for extending beams across system breaks is a rarity, and MuseScore doesn’t implement it. I had to get creative to achieve the effect, but MuseScore provided the tools. As mentioned above, pages 10 and 11 of Ch’ien show the results, which are flawless.

Item 7: Arpeggiando signs can easily be dragged to cross staves, however getting the desired playback is fussy. I’ll address the issue in my article on MuseScore playback.

Item 8: Open-ended ties aren’t common, so I expected setting them up to be finicky. It was, but not unnecessarily. I made ties to invisible notes or chords at the start of the next bar, then adjusted the starting position and length of the ties so they curved just over the barline. It’s another good example, like extended beaming, of MuseScore meeting my “never leave the user stuck” criterion.

Item 9: Slurs. They’re amazingly well implemented. Even long slurs spanning multiple staves exhibit elegance and grace. Rare were places I had to make adjustments. The only place where MuseScore fell down was when slurring from a stem-down to stem-up note; by convention, the end of the slur should go clearly into the stem of the stem-up note, not into or close to the top of the stem, which is how they presently appear.

Item 10: I expected the additive rhythms to give MuseScore the most trouble, but I was wrong. Calling up the Measure Properties dialogue in any bar let me specify the number of beats I needed, even oddities like 27/32. Many music notation programs fall down on this issue, so a big thanks to the MuseScore developers for getting it right.

Item 11: The creation of tuplets isn’t exactly intuitive, but it’s simple to do once you RTFM. MuseScore lets you specify whether you want the tuplet bracketed, which is nice because I often do, but like cross-staff beams, it isn’t possible to have the brackets horizontal by default, nor to get the handles to snap to the page grid.

Item 12: Multiple grace notes, no problem.

Item 13: Having accidentals apply only to the notes they precede made note entry painstaking, tedious, and prone to error. Because I intended to generate playback from the scores, it was necessary to add an accidental from the palette to every note needing to be raised or flattened. Furthermore, accidental-ed notes had to have their accidentals cancelled with hidden natural signs. The hidden natural signs frequently interfered with the correct positioning of visible accidentals, particularly staggered accidentals (which, under more usual circumstances, MuseScore handles intelligently). It is fortunate that MuseScore allows shifting the position of accidentals, since it didn’t leave me “stuck”, but the amount of work required to get them right was staggering. Definitely not for the faint of heart.

Given the number of scores written in the past hundred years with the “accidentals apply only to...” requirement, the MuseScore developers need to give the matter some thought. I propose a special note-entry mode where Arrow-Up doesn’t raise a note by a semitone, but rather always adds a sharp, with the same behaviour for Arrow-Down and flats. (This would also help overcome MuseScore’s hate-on for E-sharp/B-sharp and F-flat/C-flat.) All notes without an accidental would, in this mode, be treated as naturals upon playback.

Item 14: Metronome markings using the 16th note were possible, but the text field is buggy. When adding tempi markings to Kun, the default note value appeared as a dotted-quarter with no stem. Wiping it out from immediately left of the equals sign took three presses of the Backspace key—and still didn’t wipe out the dot! Also, I dislike the default “lowered and smaller” notehead style used for tempo markings, so I had to adjust the size after entering my 16th note. It would be nice if this were a settable default.

There was a playback issue, too. Although the Inspector has a “Follow text” option for tempo markings, it doesn’t. The text, “<16th-note> = 114”, unambiguously means the unit for metronome beats is the 16th, and there should be of 114 of them per minute. Playback, however, multiplied the speed by 4, indicating it was using a quarter-note as the beat despite text that said “use a sixteenth”. The solution was to uncheck “Follow text” and enter a BPM one-quarter the desired tempo. Easy enough, but “Follow text” should, to my way of thinking, mean “follow text”. If it means something else, perhaps it should be labelled differently.

That said, the idea, if not the implementation, is a great addition to MuseScore.

Item 15: Span lines were a bit of a nuisance. For example, a simple ritardando over two bars required: a) dragging a solid line from the palette to the note where I wanted it to begin; b) changing the line to a dashed line (in the Inspector); c) right-clicking the line to call up the Line Properties dialogue; d) entering “Rit.” in the text box; e) adjusting the formatting of the type and its placement relative to the line (placement defaults to somewhere in the middle of the text’s x-height); f) dragging the rightmost point of the line to the desired location. Do that often enough, and you start to get irritated.

I hope the developers will consider adding a few of the most common span lines to the palette: Rit., Accelerando, Cres., Dim., and the like. Alternatively, a method for creating one’s own span lines in the Master Palette, similar to the way one can create new time signatures, would be just as welcome.

Item 16: Adding dynamics to a score (p, mf, fff...) is a no-brainer, however there is a caveat when it comes to moving them around after they’ve been added. If you mouse-drag an already-placed dynamic too far, you risk decoupling it from the note and/or staff to which it was attached and having it attach to another. This has no effect on the printed score other than repositioning the dynamic to the desired visual location, but it does affect playback. The only reliable way to prevent a dynamic from anchoring to a different note while repositioning it is to use the Inspector to set the new horizontal and vertical offset.

Hairpins (crescendo, diminuendo) are a pain in the neck if you have need a lot of them. In theory, adding them is easy: click the notes where you want the hairpin to start and end, then hit the “<” or “>” key. Unfortunately, the default starting point aligns with any accidentals that precede the starting note, and the default endpoint is always one note further to the right than the one you selected. The left-hand problem is a bad design choice; the right-hand problem is a bug. Both meant a lot of manual tweaking.

Item 17: There is no way to add a pedal line between two selected notes (i.e. a range of notes). A pedal line must be dragged from the palette to the desired starting note, whence, by unchangeable default, it runs the remainder of the length of the bar. Pedal changes within the bar require moving the anchor of the “pedal up” mark back to the correct position one note at a time. As scores increase in length and complexity, the amount of time it takes to move backward just one note increases, sometimes by up to one second on my AMD dual-core system. The annoyance of having to move the pedal-up point backward for every single pedal change within a bar, plus the sluggishness of the operation, is enough to make a sane person go ballistic.

Though it pains me to say so, MuseScore gets a failing mark when it comes to pedaling, and I seriously hope the developers change their tune on the subject, which presently runs: The need for precise pedaling is rare (since when?), “to the end of the bar” is a sensible default length (it’s not; “to the next major beat” is), and use simile to avoid too many pedal marks, which goes against the advice of most style guides.

Item 18: MuseScore doesn’t include linespacing in its text formatting controls, which means that if you need to insert multi-line text instructions, you’re stuck with the linespacing MuseScore gives you, which is often too loose. I hope this oversight, present in 1.x as well, gets corrected.

Miscellaneous

Randomly and inexplicably, but routinely, the little arrows used to increment or decrement fields in the Inspector (e.g. the horizontal offset) begin to react twice to a single mouse click. Thus, if a click is supposed to increment by .50sp, it increments by 1.00sp instead. Once the behaviour starts, it persists throughout the session.

Anchor points for pedaling are based on the staff to which the pedal line is attached rather than to the whole system (grand staff). This means, for example, that if you have a full measure rest in the bass staff, pedal lines have to be attached to the treble staff for their anchors to be positioned correctly. Afterwards, the line has to be dragged to the proper position beneath the bass staff.

Scores exported to PDF look ghastly, at least when viewed in Okular, which is one of the most common PDF viewers on Linux systems. I haven’t seen such jaggedness in diagonal lines and curves since the early days of Mario Bros. A workaround is to export the score to PNG, which produces a separate .png file for each page. Convert each of the .png files to .pdf, then concatenate them into a single file.

MuseScore’s text-formatting is extremely rudimentary. Typographically satisfactory title pages with items like performance instructions and instrumentation are next to impossible. I typeset mine separately and join them to the PDF version of the score.

Around page 20 of the Kun score, I wanted to respell a couple of pitches. I selected the chords in question and hit Respell. From where I was in the score, the result looked like what I wanted so I saved and quit. Imagine my dismay, on re-opening the file, to discover that the entire score had been respelled! I lost a couple of days fixing everything. I’ll know better in the future, but since I’m certain not to be the only person who hasn’t read the manual before using the Respell function (which specifies that Respell acts on the whole score), it would be a good idea for MuseScore to issue a warning before performing the operation.

Finally, my Ch’ien score reveals a puzzling bug in MuseScore. Every time I save and re-open the file, it’s corrupted. Specifically, several pages worth of pedal markings are significantly out of place. The problem is not with the score itself, since before saving it, it renders perfectly on the screen. (I know, I re-entered the pedal marks dozens of times.) I’m not sure how MuseScore can render a file perfectly when it’s open (pre-save/close), but mangle it upon re-opening. Potentially a serious bug, even though, at present, no one else seems to have encountered it, and only Ch’ien is affected.

Summary

While the final version of my two scores shows beyond a shadow of a doubt that MuseScore 2.0 allows one to create beautiful scores to exacting standards, it doesn’t always do so as efficiently as I believe it could. On the basis of my “never stuck” criterion, I give MuseScore 2.0 a solid 10/10, but issues with dynamics, hairpins and pedaling lower the mark to 8. The developers are, however, marvellously responsive to bug reports, suggestions and feature requests, so I expect that MuseScore will soon reach 10/10 in all areas concerning the creation of printable musical scores.