Today MuseScore announced the release of MuseScore 2.3, featuring the brand new MuseScore Extension facility to allow additional packages of features to be easily delivered and installed without the need to update the program. These extensions can include new instruments and sounds as well as new palettes and other enhancements. In conjunction with MuseScore 2.3, MuseScore is releasing the first such extension, MuseScore Drumline.
Of course, there are also numerous other new features and bug fixes in MuseScore 2.3. You can download it from The MuseScore web site. The official announcement and the release notes cover a lot of the details, but I’d like to go into a bit more depth on some of the most significant things you can expect.
[Editor’s note: Scoring Notes contributing author Marc Sabatella is Director of Education for MuseScore and the author of Mastering MuseScore, an extensive guide to MuseScore. Because of Marc’s position with MuseScore, this post does not constitute a Scoring Notes review of MuseScore.]
MuseScore has long supported a variety of customizations, including the ability to install new soundfonts, edit the list of instruments, create your own templates, palettes, etc. What it has lacked is a way to package a set of these customizations so that an ordinary user can easily install them, update them, or uninstall them without the need to deal with a confusing mess of different configuration files. The new MuseScore Extension facility addresses this need by providing a simple interface for these actions.
MuseScore Extensions are accessed from Help > Resource Manager:
This interface allows us to provide new extensions and updates to existing extensions, and it allows you to install or uninstall them, without the need for a whole new version of MuseScore. The MuseScore Drumline extension we are releasing now is but the first of many we plan to provide.
There are a number of percussion-related improvements in support of the new MuseScore Drumline extension, but there are also other changes of more general interest that I would like to highlight first.
Every new release comes with bug fixes, and MuseScore 2.3 is no exception. Dozens of issues reported by users have been fixed for this release. This includes a number that were inadvertently introduced in MuseScore 2.2 as well as others that have been with us longer.
One example of a problem that was new in MuseScore 2.2 and is now fixed has to do with how the score repositions itself within the window as you work on it. I choose to discuss this bug because it illustrates one of the truly wonderful things about how things work in the open source world. The original report noted that in certain cases, when pasting to a measure that was originally very close to the right-hand edge of the window, the score would jump all the way to the left. This was a bug, plain and simple, but when it was first noted on the forum, it generated a rather passionate discussion that led to a greater understanding of the different sorts of ways people use MuseScore, the different types of devices they use, and how these differences affect expectations about how the score will respond.
As a result, not only did we fix the bug, but we tweaked the algorithms further to improve the overall experience and introduced a couple of new features to give users greater control over score positioning. One of the users in the discussion did some of the coding for this; more on this below.
The discussion about the score repositioning bug led us to implement an option that a few people have long requested: the ability to completely turn off automatic score repositioning. Normally, MuseScore will automatically reposition the score to keep the active area in view, so as you reach the right-hand edge of the window, the view moves so you could see the notes you are entering.
For example, here I am about to enter a “C” to complete the scale:
After entering the “C”, the score is repositioned so I can see the next measure:
This is all well and good if my intent was to continue with the next measure. But what if I had really wanted to continue working on the previous measure, such as by entering another voice or adding dynamics? With piano and guitar music in particular, this can be especially common.
To deal with this, we took the little-used Pan score during playback toolbar button (to the left of the metronome button) that disabled score repositioning during playback, and we repurposed it as pan score, period. So now, if you disable that button, the score will not be repositioned automatically at all. Entering a “C” with the button disabled will result in the following:
The default behavior here continues to be as before.
There is also a new option in Edit > Preferences > Canvas to prevent the user from accidentally moving the score too far when scrolling manually. Normally, it is possible to move the score into the following position:
Some people might see this behavior as a bug, but it can actually be valuable for keeping focus in one location as you zoom in and out. Still, for some workflows, it is detrimental. With the new Limit scroll area to page borders option, MuseScore will simply stop you from scrolling the score so far that large areas of blank canvas appear. This can be especially useful for users of the Mac trackpad or other devices that encourage free scrolling.
These may seem like small things, but they have represented pain points for a number of users, including people trying to synchronize the score display with a PDF file when doing the valuable work of engraving music as part of the OpenScore project. So we’re happy to be able to address these concerns.
Instrument / synthesizer / soundfont improvements
Like MuseScore 2.2 before it, MuseScore 2.3 is focused on playback improvements to a greater extent than in the past. The default MuseScore_General.sf3 soundfont continues to be improved, and so do our two internal synthesizer modules (Fluid for Soundfont formats SF2/SF3 and Zerberus for SFZ format).
Zerberus in particular is receiving greater attention as we move forward, since the SFZ format contains a number of advantages that make it the better choice for those seeking more realism. Our original implementation of Zerberus in MuseScore 2.0 was limited to just what was needed for the Salamander piano soundfont. Over time this has been expanded to provide more of the features needed by other SFZ soundfonts.
For MuseScore 2.3, we have really pushed our support for this format even further, allowing MuseScore to better take advantage of its wide range of expressive capabilities. The new MuseScore Drumline soundfonts benefit greatly from these improvements, as will many other SFZ soundfonts.
Also as part of the broadening of our focus beyond just notation, we continue to add to the list of instruments you can select from when setting up your score, and we have reorganized the list a bit to make it easier to find what you are looking for.
Percussion notation and playback improvements
As you may be realizing from the mentions of the MuseScore Drumline extension, a major focus for 2.3 has been on percussion. The improvements are almost equally divided between notation and playback. While the MuseScore Drumline provides a number of additional enhancements for those who choose to install the extension, many of the underlying features it relies on are available even without it.
On the notation side, the two main additions are the “Z” notation for buzz roll (found on the Tremolo palette) and a plethora of new noteheads – over 100 in all – that can be assigned for use in the Edit Drumset window. Not only are there many new noteheads to choose from, but you can also assign specific noteheads for quarter note, half note, whole note, and double whole note.
Together, these features greatly increase the range of notations you can create for drums. They also greatly increase the ease with which you can create them, once you have set up your drumset definition as you like it. Even better, the buzz roll and many other articulation markings are now supported for playback using different MIDI pitches to trigger different samples. So if the soundfont you are using includes separate samples for buzz rolls, staccato, or other markings, then MuseScore can potentially play these back using those samples rather than merely adjusting volume or note length as it otherwise might.
Unfortunately, General MIDI does not include definitions for these sounds, so standard soundfonts won’t include them. So, that is part of the reason why we created our own set of drumline soundfonts, which include buzz rolls, flams, and all sorts of other sounds. And we also wanted to create drumset definitions that take advantage of these new sounds. That is what led to the development of the new MuseScore Drumline extension.
The MuseScore Drumline extension (MDL) is an exciting new development that is designed to meet the unique demands and workflows of marching music directors, composers and arrangers. As with other extensions we will eventually provide, the MuseScore Drumline can be installed via Help > Resource Manager. Once installed, you will have access to a number of new features.
The starting point for most scores using the MuseScore Drumline extension will be one of the new templates that are available in the Create New Score wizard. Here is a sampling:
In addition to the ready-made templates, MDL provides a number of new instruments you can select from when setting up a score for your own ensemble:
Each of these instrument definitions has been designed to easily support all the common notations and sounds that are typically used:
One particularly interesting instrument is the MDL Rail, which is a single-line staff intended to be used as an adjunct to an ordinary pitched instrument. This allows you notate quick instrument changes for performers with simultaneous pitched and unpitched percussion responsibilities, such as a marimba or other keyboard percussion instrument performer also having suspended cymbal rolls, cowbell hits or any other of the number of other percussion instruments that are often attached.
Once your score is set up and you have begun adding notes to it, you can also add the many symbols found in the new palettes that are provided as part of the MDL workspace.
A number of these symbols are programmed with the proper playback. For instance, the first few elements on the MDL Front Ensemble palette shown above will change the playback sound between marimba, xylophone, vibraphone, and glockenspiel.
While the MuseScore Drumline extension provides much to appreciate on the notation side, playback is an equally important aspect. Soundfonts are provided for traditional drumline instruments such snare, tenor, and bass drums, cymbals, flubs, and drumset. The soundfonts provide a wide variety of different sounds for each drum, including versions for solo snare and tenor versus entire snare and tenor lines, and the sounds include multiple samples to allow for natural-sounding variation from note to note.
MDL notation references
The MDL notation references describe how to take advantage of the MDL instruments in your drumline scores. These guides are not actually installed with the extension but are available online.
Here is a sample from the MDL Snareline reference:
Q & A with Daniel Ray
Following is a Q&A with Daniel Ray, who was the impetus behind the MuseScore Drumline extension.
Marc: MuseScore 2.3 is making a very strong outreach into the marching and percussion world. What prompted this?
Daniel: It is really a combination of factors, but like any decision it comes down to firstly data, and then any other unique insights, experience, relationships or other factors you feel may guide a specific path versus alternatives.
In this particular case, starting with the data, if you take a look at the NAMM Global Report for the past several years, there are only two segments in the entire music industry that are actually experiencing growth: electronic music and marching percussion.
From this data, we look for opportunity and consider how we may uniquely participate. This is where we jump back to the insights, experience or relationships that I mentioned before and how MuseScore could be positioned to uniquely engage.
In regards to the marching percussion segment, not only did we believe that MuseScore could offer value here, this is an area where I happen to have considerable relationships and experiences. I grew up actively involved in marching bands as a kid, playing in a drumline, then went on to participate in competitive drum corps where I was drum major for what may be considered one of the top marching groups out there, The Blue Devils.
After this, I went on to work with other similar drum corps, Crossmen, The Cadets, and taught a number of bands and winterguards.
So, while it was the data that really identified the opportunity, it was ultimately my personal experience that prompted the final decision.
Marc: How do you see the MuseScore Drumline extension being used?
Daniel: I think the more interesting question here is not necessarily how will it be used, but who will use it?
Until the release of MuseScore Drumline, to get even close to a similar experience in terms of capability for marching percussion notation and playback, it required a minimum investment of around $600-700. On top of that, to be able to notate accurately would require a considerable level of understanding of best practices for marching percussion notation in addition to learning to use software that was designed and configured for the professional composer or arranger.
The fact that MuseScore is free, that MuseScore Drumline is also, this opens up access to an entirely new segment of creators, but with this new segment comes new challenges.
Notating for marching percussion or any type of rudimental percussion is not so easy. To do this correctly and consistently is a challenge for young or less experienced composers. With this in mind, we created a series of templates that actually make it somewhat complicated or at least require a higher level of skill in order to notate incorrectly, versus simply opening a template that forces these best practices automatically, in a way that is not even noticeable to the end user.
The best metaphor I can think of for how these templates are designed are the bumpers used in a bowling alley to fill the gutters for beginners. It makes errors difficult and success pretty much guaranteed.
Marc: Are there particular composers using MuseScore whose work you would like to highlight?
Daniel: Rather than highlighting a particular user, there is a particular group of users within this segment that I am in absolute awe of. These are kids, and I do mean kids 15, 16, 17 years old who are watching videos online of drum corps performances and transcribing full scores based only on grainy YouTube videos shot on mobile phone. These are full scores — 70 brass, full battery and percussion parts.
Not only are they notating these scores, but they are tracking changes in the score from performance to performance and have the changes done within hours. Unbelievable.
Marc: Are there any future plans regarding the MuseScore Drumline, or any other planned extensions we might expect to see some day?
Daniel: Well, here is the great thing – extensions can be released and automatically updated completely independent of the software cycle.
What this means is that if, based on feedback from users we should adjust the timbre of a rimshot on a snare drum or the the hand mute on the 8th bass drum sounds just a bit too dead, we tweak it and put it out. Users are notified they have an update and it smoothly installs.
This iterative process and evolutionary experience means that improvements can be made, updates automatically installed, as often as users within that segment may demand.
Which leads me to the next part of your question, yes. I believe that extensions will be an important part of the future of MuseScore and the best way we can serve the general needs of users as a whole, while uniquely supporting the needs of individual communities.
In thinking about what may be next in terms of extensions, I consider what currently exists in MuseScore that could be expanded on to better serve the community. MuseScore does already serve some very unique niches – harp, bagpipes, early music, and so on. Features designed exclusively for these segments have already been incorporated into the core features of MuseScore.
I consider that these users might be better served by moving some of these elements to extensions, which may be further developed to provide even better support for their unique needs, and that can also evolve independent of the software development cycle.
This idea, this concept, this is really what MuseScore 2.3 is about, a first step into a future that I am truly excited about being a part of.
With MuseScore 2.3 released, we again turn our attention to MuseScore 3, which will be a major release introducing some powerful automatic layout facilities and other advances. It has been in the works for three years already and is really starting to take shape.
Meanwhile, I would like to contribute the tradition of recognizing the work of some of the contributors to this open source project.
One of the unsung heroes of the whole MuseScore 2 series has been Jean-Bernard Roy, known in the community by his nickname cadiz1. Jean-Bernard is a French classical guitarist and teacher. While not a programmer, he has helped with development immeasurably through his tireless efforts in reporting bugs and, to our constant amazement and eternal gratitude, in helping us ascertain when and how a bug was introduced. You see, open source projects like MuseScore typically produce “nightly builds” for testing, and Jean-Bernard has archived them all since 2014. Whenever a particularly tricky bug is reported (whether by himself or another), he works to reduce it to the simplest possible example, and then he goes through his archive testing the nightly builds to determine exactly which day the problem appeared. Even more, because this all open source, he is also able to determine which lines of code changed on that day. This is exactly as painstaking a process as you might imagine, and he has done this hundreds upon hundreds of times over the years. Once we know when and how a bug was introduced, it becomes a much simpler matter to fix it. Jean-Bernard tells me this sort of successful detective work gives him great personal satisfaction. As a developer, I can relate to that feeling as well, and we feel incredibly fortunate to have him on board.
A more recent contributor to the project is pianist and choral singer Matt McClinch. Matt has been a MuseScore user for several years but just started contributing as a developer. In just the last few months he has learned his way around much of the code and has managed to fix a wide variety of some of the thorniest problems reported of late. I don’t have any stats to back me up on this, but I can hardly think of anyone who has come up to speed faster or contributed more in such a short time. Matt was one of people instrumental in the discussion regarding the score repositioning and the resulting changes. In addition to this and other usability improvements, he has also made significant fixes in areas as diverse (and complex) as score layout and playback. We look forward to his continued contributions to the project.
In conclusion, we could not be more excited about the state and direction of MuseScore!