MuseScore 2.1 released

MuseScore today announced the release of MuseScore 2.1. This is the sixth release in the MuseScore 2 series, and it represents the most significant update to MuseScore since the MuseScore 2.0 release in 2015.

For those unfamiliar with MuseScore, it is a leading open-source and cross-platform WYSIWYG notation program. MuseScore 1.0 debuted back in 2011, and after a few minor updates over the next four years, 2015 brought a major overhaul in the form of MuseScore 2.0. It was this version that introduced linked parts, tablature, significant engraving improvements, and a number of other features designed to bring MuseScore into the realm of professional scoring applications.

After a series of “point” releases that focused primarily on bug fixes, work began on the next major leap forward, which will eventually become MuseScore 3. As technical contributor to MuseScore, my colleagues and I realized that much of what we were planning could not be accomplished without breaking backwards compatibility, and we also realized it would be a long time before it was ready. While work on MuseScore 3 continues, we did not want users to have to wait too long for new features.

Thus was born MuseScore 2.1 — a release that includes as many improvements as practical given our goals of maintaining compatibility and providing timely updates.

MuseScore 2.1 arrives with dozens of new features and other enhancements (as well as hundreds of bug fixes, of course), and yet MuseScore 2.1 files can be opened in previous MuseScore 2 releases and vice versa. The full list of changes found in MuseScore 2.1 can be found in the release notes.

In this article, I’d like to highlight some of the more noteworthy improvements.

New features

One of the great things about open source software is how users can become developers and “scratch their own itches,” as we sometimes like to say. That is, any user with programming experience and an idea on how to do things better can get involved and make it happen. With 20 new first-time contributors since the last release, there are now exactly 100 developers who have helped make MuseScore what it is today.

Several of the most exciting features in MuseScore 2.1 were added by some of our newer community members. Some of this work was performed by students sponsored in part by the Google Summer of Code program. Meanwhile, the core team (Werner Schweer and Nicolas Froment) and other stalwarts have continued to work to ensure MuseScore is as powerful, easy to use, and bug-free as it can be.

New note input methods

MuseScore has long been able to import standard MIDI files, and in fact is recognized at being especially good at rendering them in standard notation. Until now, though. there has been no way to just record a passage directly into an existing score via MIDI.

This has been one of the most requested features since the very early days of MuseScore, so we are especially pleased to be able to offer it in MuseScore 2.1, with not just one but two different real-time note input modes. In the automatic mode, a metronome clicks and you enter notes in tempo. In the manual mode, you tap out the tempo yourself with a foot pedal or other device. Either way, you start by selecting the shortest duration you want MuseScore to use in quantizing, then begin playing. MuseScore automatically interprets the rhythm of the notes you play and notates it correctly according to the time signature.

A nice bonus of this feature is that the algorithm to group rhythms according to time signature is also available outside of the real-time note input mode. That is, you can use this feature — accessed as Layout > Regroup Rhythms — to correct rhythms entered via other methods as well.

For example, it can automatically turn this:

into this:

In addition to the new real-time input modes, MuseScore 2.1 also provides another new input mode requested by users of other programs such as Denemo, in which you first enter a rhythm using the keyboard shortcuts and then go back and specify the pitches. All three of these new input modes were implemented by newcomer Peter Jonas as part of Google Summer of Code 2016.

There are also new commands that make it easier to modify the duration of a note just entered in the default step-time note input mode, such as to add an augmentation dot after entering the note rather than needing to select it as part of the duration before entering the note.

Playback improvements

Starting with MuseScore 2.0, we have provided limited support for the SFZ soundfont format, but these limitations prevented the full use of many popular SFZ soundfonts. MuseScore 2.1 addresses many of those limitations, allowing MuseScore to take more complete advantage of the SFZ format and thus achieve greater realism in its playback. For instance, we now support loading multiple SFZ soundfonts at once as well as use of round robin samples, loops, and envelopes. There are also improvements in the handling of the SF2 format and in our customized version of the FluidR3 soundfont that we use by default. Most of this work was completed by new contributor Johannes Wegener, also as part of Google Summer of Code 2016.

On a related note, the score sharing site musescore.com that allows users to upload their scores for others to enjoy now allows you to upload your own audio along with your score. So if you have installed third party soundfonts — including ones in SFZ format — and use those when playing your score on your own system, then visitors to musescore.com will hear your score played using these same sounds rather than with the default soundfont. This is also a feature that has long been requested by users of musescore.com.

These and other playback features are demonstrated in this video:

A little-known fact about the tablature system in MuseScore 2 is that it was originally designed for notation of Renaissance music, although of course it also handles rock and other modern styles well. MuseScore 2.1 adds support for more features required by early music aficionados, including notation for lute bass strings. This feature was the product of work originally done by long-time MuseScore developer Maurizio Gavioli and then adapted by first-timer Markus Lutz.

Selection controls

MuseScore provides two different types of selection: range (contiguous from one point in time to another) and list (individual elements that may be discontiguous). In addition to the methods MuseScore 2 already provides to make and alter selections, MuseScore 2.1 adds some new capabilities.

For example, one type of operation that one sometimes wishes to perform is to select all notes with a pitch of G and to raise them to G#. Another might be to select all quarter notes within a range and add staccato dots to them. In MuseScore 2.1, you can accomplish this by right-clicking a note and going to Note > Select > More, which provides new options to select notes according to various different criteria such as pitch, duration, and notehead.

MuseScore also provides a Selection Filter that allows you to exclude elements of certain types from a range selection. For example, by excluding lyrics from a range selection, you can copy everything in a passage except the lyrics. You can now easily include or exclude all element types with a single click.

Another new feature is the ability to swap a range selection with the contents of the clipboard. This can be used to easily exchange two different passages without the need for a scratch staff. Simply select the first passage, cut or copy it to the clipboard, select the second passage, swap it with the clipboard, then re-select the first passage and swap again.

More new features

There are quite a few other new features in MuseScore 2.1, including the following:

• The ability to reorder the tabs for the various scores you have open
• New templates for marching and concert bands as well as other ensembles
• New instruments including a general percussion staff, instruments treated as transposing with standard clefs rather than octave clefs, more ethnic instruments, etc.
• Simple control over brackets for accidentals
• Customization of playback behavior for breath and pause marks
• Customization of bitrate for exported MP3 files
• Customization of breaks between scores in joined albums
• Improved controls and arrangement of various dialogs

For more information, see the release notes.

Other improvements

In addition to the new features, MuseScore 2.1 includes hundreds of bug fixes and other improvements. There are far too many to list (that is what the release notes are for!) but as one of the developers, I would like to highlight two that I worked on. Either of these might be lost in a long bullet list of bug fixes, but I think they illustrate nicely some of the ways that open source software can directly involve users in the development process, both through the desire to “scratch your own itch” and also through pride of craftsmanship.

Similar stories could probably be told about many of the changes listed in the release notes, but the specifics are not what is important. My point is just to give you you a taste of what goes on in development of an open source program like MuseScore.

Transposition of mid-score instrument changes

MuseScore 2 introduced the Instrument Change element, which allows you to change the instrument used for a staff mid-way through a score. However, while this affects playback, it does not affect transposition in MuseScore 2. So if you have a part for alto saxophone (an Eb instrument) in which one passage was to be played on clarinet (a Bb instrument), you can get it to playback correctly but not to print correctly, or vice versa, but not both — at least, not without convoluted workarounds.

Fixing this was not actually all that difficult, but at first glance it appeared that the fix would introduce an incompatibility. Scores created using older versions of MuseScore would work differently if loaded into newer versions of MuseScore. So the fix was slated for MuseScore 3, which we knew will break compatibility in other ways as well.

But to me, this one issue seemed to be one of the biggest things getting in the way of more widespread adoption of MuseScore as a serious arranging tool for jazz musicians and others who often deal with transposing instruments. And I would love to see that widespread adoption happen. So I worked to find a solution to the compatibility problem and to incorporate this fix into MuseScore 2.1.

I looked at the different workarounds people had employed to get correct display and playback, and I analyzed what the desired result would normally be — correct print or correct sound — in a variety of different situations where people had not employed any such workarounds. In the end, I found a reasonable compromise, where most scores already created in MuseScore 2 would either work the same when loaded in MuseScore 2.1 or else they would be automatically fixed.

This is but one example of how we approached the addition of new features and the compatibility concerns that might be involved. No doubt there will be some scores that will still require some fixing up, but since the situation in MuseScore 2 was not good in this respect, I think people should be happy with the change overall. And I am happy to be able to take advantage of this feature in my own scores!

Fixes for “wandering hairpins”

Most developers would probably agree that the most frustrating type of bug report is where someone encounters a serious problem that the developers cannot reproduce. We can see that the problem exists for the user, but try as we might, we cannot make it fail ourselves.

One such example in MuseScore 2 involved cases in which a user would carefully customize the position of a crescendo or diminuendo marking and save the score, only to find upon opening the score later that the hairpin had wandered off somewhere, appearing as if he had applied some totally different manual adjustment. Several users posted stories of this, complete with screenshots, but even when they included their actual scores and steps to reproduce the problem, we couldn’t get it to fail for us.

It became a bit of an intellectual challenge for the users affected by this problem to figure out how reproduce it reliably, and for developers to be able to confirm such a case. After months of the rest of us getting nowhere, someone finally managed to come up with one case we were able to reproduce, but even then the underlying cause proved hard to pin down and so no fix was found. Eventually another reproducible case was found, and then another, and another, but it was not obvious what they had in common other than the end result, and again, no fix presented itself.

Even though I personally had never been affected by this problem, I did not like the idea of continuing to push my luck on this, nor did I like seeing others bit by it. So I decided to try to get to the bottom of this for MuseScore 2.1. It took a while to unravel, but in the end I found not just one but three completely separate bugs that were causing this behavior. Scores that contained any of several specific combinations of repeat or double barlines, changes in scaling, courtesy key signatures, line breaks, and ties between notes of particular stem directions would trigger a difference in the widths of certain measures, which in turn triggered a discrepancy in the position of the hairpin. We managed to get all three fixes into MuseScore 2.1.

I can’t say with any certainty that we caught all cases of wandering hairpins for 2.1, but I will suggest that this demonstrates spirit of open source software and how the involvement of users in its development can really work.

What’s next

Several times, I have mentioned the ongoing work toward the development of the MuseScore 3. The primary focus of that release will be making MuseScore “smarter” with respect to layout, automatically detecting and resolving collisions between score elements. This is important not just to reduce the amount of time engravers spend performing manual adjustments, but also to facilitate delivery of scores via electronic means, such as the MuseScore Songbook app for iOS and Android. No matter how good you make your score look on your own computer or printed on paper, all bets are off if a user of a mobile app decides to change the font size or transpose the score, thus changing how measures fit on lines and lines on pages and potentially destroying your careful customizations. So we are working to make all that work better.

For more on this, see Isaac Weiss’ blog article, MuseScore 3.0 under development: MuseScore gets smart. There is much more to MuseScore 3, but that gives you some idea of the scope of what we are trying to achieve.

Meanwhile, though, MuseScore 2.1 is here for everyone to enjoy right now! So go ahead and download and start using it. We welcome you to join the user community at musescore.org and to participate in the forum discussions there. You can ask for help, make suggestions, report bugs, and find other resources there. You can also make a monetary donation if you are so inclined. And if you start to feel an itch to help improve MuseScore further, we encourage you to scratch it by getting involved!

Marc Sabatella is a jazz pianist, composer, and educator who teaches theory and improvisation at the University of Denver. He has degrees in both music and computer science, and he is a technical contributor to MuseScore. Marc is the author of the comprehensive guide Mastering MuseScore as well as books on jazz theory and improvisation.