MuseScore 3.2 has been released, marking the latest in a series of updates since the original MuseScore 3 release that we wrote about here back in January. Some of these releases have been minor bug fix updates, but several have introduced significant new features as well. If you haven’t been following MuseScore closely, you might be surprised to see how much has happened since the release of MuseScore 3 just six months ago.
MuseScore 3.2 was released on June 25, 2019. As of the time of publication of this post, 3.2.3 is the latest version, released on July 8, 2019. Let’s take this opportunity to talk about some of the most notable changes.
[Editor’s note: In addition to being a Scoring Notes contributor, Marc Sabatella is the Director of Education for MuseScore.]
New features
Single Note Dynamics
For many years, one of the most requested features has been the ability for the volume of a single note to change over the course of its duration during playback — for a crescendo on a sustained note to gradually get louder, or for a fortepiano dynamic to suddenly decrease the volume of a note after the initial attack. MuseScore has always used the traditional MIDI approach to dynamics, where volume is determined by the initial velocity of the note and cannot be controlled after that.
In order to support the new Single Note Dynamics feature, MuseScore needed to switch to an approach based on the use of continuous controllers, which was no small feat. This task was undertaken by developer James Thistlewood and soundfont designer S. Christian Collins, and the feature is now available. It works right out of the box for both new and existing score with the default MuseScore General as well as the new optional MuseScore General HQ soundfonts. There are also options in View > Synthesizer > Dynamics to control the behavior of the facility in ways that allow it to work with a wide variety of other soundfonts.
Here is a demo of Single Note Dynamics in action (click here, or on the image to listen on musescore.com):
More flexible automatic placement
The Automatic Placement feature (autoplace, for short) was one of the great breakthroughs in MuseScore 3, providing collision avoidance that eliminates the need for most adjustments. But although it was possible to still adjust elements manually where needed, users sometimes felt that autoplace was getting in the way, preventing them from placing an element where they wanted. And while it was possible to disable autoplace where needed, this was often undesirable, as it meant there would be no collision avoidance at all for the affected elements.
So, after some creative reworking of the collision avoidance algorithms, MuseScore now allows you greater freedom in your manual adjustments, to the point of allowing you to deliberately create collisions, move elements from one side of the staff to another, and more, all without ever disabling autoplace. MuseScore also now provides additional controls over the default behavior, including more settings to control minimum distances for collision avoidance and a keyboard shortcut = (equal sign) to disable autoplace where needed.
Here is an illustration of some adjustments that are now possible without disabling Automatic Placement:
Rapid entry of sticking, fingering, and other text
First: Sticking is a new feature in itself — a percussion version of the fingering markings used for piano, guitar, and some other instruments, in which the usual sticking markings are R, L, r, or l.
Second: For Sticking as well as Fingering, MuseScore now allows a very easy way of entering these by typing in your score, pressing Space to move from note to note, just as you would enter lyrics or chord symbols. This feature can also be used with other forms of text, although the shortcut is Alt+Right instead of Space, because most other text types are likely to contain spaces themselves.
Here it is in action:
Changing durations
Previous versions of MuseScore allowed you to change the duration of a single note (select the note and click the duration icon on the toolbar or use the corresponding keyboard shortcut 1-9), but there was no way to change the duration of multiple notes at once. So if, for instance, you had a series of half notes played by several instruments, and you wished to change them all to quarter notes (followed by quarter rests), you had to make the change one note at a time, one instrument at a time.
The current version of MuseScore now allows you to change them all at once, using the same commands as for single notes:
This command preserves the original rhythm, inserting or deleting rests as necessary. But sometimes you may wish to actually halve or double the durations and rhythms for a passage — converting a 2/2 passage to 4/4, or creating an augmentation or diminution of a phrase for contrapuntal purposes.
MuseScore now supports Paste Half Duration and Paste Double Duration commands (in the Edit menu) that accomplish this quickly and easily:
Unroll Repeats
Another new feature for quickly transforming your score is Unroll Repeats, found in the Tools menu. This command creates a copy of your score in which all repeated sections are written out in full. This can be useful for a number of reasons, such as allowing you to prototype an arrangement using repeats and then unroll to flesh it out with variation between repeats.
The effect of the tool is to turn this:
into this:
Other improvements
Design refinements
MuseScore developers have long been dedicated to the goal of usability, but the finer points of user interface design did not always get the attention it deserved. That all changed when designer Martin Keary (@tantacrul) posted his video review of MuseScore recently. His reviews are typically direct in their criticisms but delivered in a light-hearted and extremely entertaining style, and this was no exception. After he roasted Sibelius in a previous video, we were apprehensive about what he would say about MuseScore, but we had to admit that most of his points were right on the money. So, we immediately set about seeing what we could do to address his concerns.
In very short order, we tweaked the icon and logo, altered some of the interface colors to improve consistency and reduce confusion, clarified the wording of various controls, started making better use of space in the Inspector, and made the behavior of certain commands more intuitive and efficient. This work is ongoing, and we hope to follow up soon with a more in-depth look at the ways we have responded to his thoughtful commentary.
Here is one example of a change made – dragging a note now affects the spacing by default rather than merely moving the note.
Better performance
One of the long-standing complaints about MuseScore had been its poor performance on large scores. Much of this was due to the fact that we always performed a full re-layout of the score with every edit. With MuseScore 3, we introduced optimizations so that most commands would only require a layout of the portion of the score actually affected, and this helped a lot. But this optimization only worked in Page view as opposed to Continuous view, and there were a number of commands that still forced a full re-layout unnecessarily.
As of MuseScore 3.2, we are now much more consistent about only laying out what is needed, leading to MuseScore being many times faster on large scores than ever before.
Increased stability
MuseScore 3 was a monumental effort, the result of four years of development and involving hundreds of thousands of lines of code. With any software release that large, bugs are practically inevitable, and MuseScore 3 was no exception. There was some grumbling at first about the initial MuseScore 3 release not being as stable as MuseScore 2.3.2 before it, and we took this feedback to heart. With hundreds of issues fixed since then (including, to be fair, many that existed in 2.3.2 as well), we have reached a point where even those who were the most skeptical at first are now impressed with how stable and powerful MuseScore has become. So for anyone who has been holding off on checking out MuseScore 3 “until the kinks are worked out,” we would humbly like to suggest that now is the time!
Contributors
MuseScore is open source software, meaning that anyone with the necessary skills who wants to get involved can do so. Some time ago, we passed the century mark in terms of number of contributors, and new people are constantly joining the effort.
One relatively new contributor I would like mention especially is James Thistlewood (@TheOtherJThistle), who was instrumental in the development of the Single Note Dynamics feature. James is a student who has been using MuseScore for a while, and the limitations in the playback of dynamics were something he had noticed right off the bat. At first, he assumed it was something he would have to wait for an update to address. But eventually he realized he wanted to find a way to give back to the open source community and MuseScore in particular, and this made a natural choice for his first major project. And it was a major project indeed.
Single Note Dynamics involved not only an enormous amount of code (almost 10,000 lines) but also working closely with others (including the aforementioned S. Christian Collins) on making sure that the soundfonts used would support these changes. This achievement would have been a significant career milestone for almost any software developer, but it is especially remarkable for one so young. James encourages anyone else with an interest to consider contributing as well, and we hope others are inspired by his example.
We also value the role of non-developers who are actively involved in testing, reporting problems, making suggestions, and helping support other users. Mike Nelson (@mike320) has been a MuseScore user for several years, and the MuseScore community has become a major part of his life over that time. A particular interest of his is transcribing classical scores and making them available to blind musicians for conversion to accessible formats like Braille. Mike was among those who expressed reservations about the stability of MuseScore 3 initially, but he then committed himself to helping improve the situation. Through his numerous well-written bug reports, his work helping organize, track, and prioritize issues raised by others, his monthly “MuseScore 3 at (N) Months” series that helped bring our progress and the remaining challenges into focus, and the many forum posts he has written helping others learn to work with MuseScore 3, Mike has been a key part of the current success of MuseScore. Recently, he has begun brushing up on C++ programming and looking for ways to get involved in that way, and we look forward to his continued contributions.
What’s next
MuseScore has once again been selected to participate in the Google Summer of Code (GSoc) program, and Google is now sponsoring four students who are hard at work improving MuseScore further. GSoC has always proven to be a fantastic program for the students and for the open source community, so we thank Google for their continued support.
Meanwhile, the MuseScore team remains committed to regular updates to fix bugs, add new features, and generally make MuseScore the best we can. We are in the process of developing an official roadmap for the coming months and years, so stay tuned for further announcements.