MuseScore 2.0 brings better music notation, improved usability
Much anticipated major update of MuseScore brings score layout improvements, linked parts, guitar fret diagrams and tabulatures, the importing of Guitar Pro files, and more exciting new features.
For a more or less complete list of changes please read release notes or just download and make your own judgement. There’s also a great video from George Hess with highlights of the new release:
A week ago, LGW already interviewed some of the MuseScore developers, when Open Well-Tempered Clavier project was released, but there is just so much to discuss when it comes to the score editor. Thomas Bonte and Nicolas Froment kindly replied all the questions.
After this much rewriting MuseScore, are you happy with the outcome, or do you still see some flaws in how MuseScore works internally and/or with regards to UI?
Nicolas: We are very happy with the outcome. The core of MuseScore, a single code base, is running on the 5 major OSes of the moment. But of course, being perfectionists, we do think there is still room for improvements.
If I would have to pick a single one, it would be layout speed. Currently MuseScore will relayout the full score for any edit, we could optimize this.
My impression from our past conversation several years ago was that you didn’t intend to push MuseScore to take on Sibelius or Finale. Back then, the app was often compared to Finale Notepad. Where would you position MuseScore today?
Nicolas: In term of features, we believe MuseScore covers the vast majority of the engraving features of the two software packages you mention, and these features are probably the most used ones. MuseScore also provides some other features that they do not provide (import of several formats for example). MuseScore’s goal remains to provide an affordable, easy to use music notation software which creates beautiful sheet music.
MuseScore used to be criticized for score output quality. However, things seem to have improved with 2.0. What’s your approach to working on this? Do you mostly rely on input from users or do you run various continuous comparative tests?
Nicolas: The approach is the same than for any other open source software. Something looks wrong or broken, and a developer thinks he can fix it, so he scratches his own itch. It happened repeatedly to Marc Sabatella during the development period of MuseScore, and so he worked on handling second intervals in multivoice context, stacking accidentals, beam groups etc.
During the last development cycle, Elaine Gould published the “Behind Bars” book which is now recognized as a reference for music notation. The book helped us a lot to make things right.
Of course, music notation is far from an exact science even with a reference book, and sometimes we needed some discussion to find a compromise. When a decision is made and implemented, we use visual tests to make sure there are no regressions.
One notable change in 2.0 is Zerberus — a new built-in SFZ sampler. For the older sampler, you are still shipping an SF2 soundfont that is better, but still somewhat simplistic. Should we expect you to continue improving built-in playback with regards to output quality? Maybe do a kickstarter to create a really high-quality soundfont with instruments recorded all in one place by the same engineer (that is, unlike the Sonatina SFZ frankensamples)?
Nicolas: MuseScore 2.0 comes with a new soundfont, derived from FluidR3GM, which was the default on Ubuntu, but not in most other distributions and on Mac and Windows. For those used to the old soundfont, the quality will increase dramatically already in 2.0. The SFZ sampler, Zerberus, has been implemented with the Salamander Piano soundfont in mind. For piano scores, it gives a very good result. Check this page for a comparison.
We would love to work on a better playback in future versions, but we need to keep in mind that MuseScore is first and foremost about notating music. Any playback improvement shouldn’t go in the way of easily creating beautiful sheet music.
We hope to be able to improve the internal synthesizers and to offer an even better connection to JACK for more demanding users. Some developers have show interest on working on VSTi support, but so far no work started, and the license status of such an implementation, VST being a proprietary standard, is still unclear.
The idea of a kickstarter to create samples and soundfont has been raised several times. So far nobody took this challenge on to make it reality.
How much and in what ways do you interact with educational institutions today?
Nicolas: We interact with educators and institutes via the same channels as with use with our users, that is email and via the MuseScore forum. Many schools are using MuseScore and we mostly learn about this fact via a student’s tweet or support request in the MuseScore forum.
School network admins reach out to us to get help deploying MuseScore on Windows network. It’s one of the reason why MuseScore on Windows is delivered as a MSI, to ease this deployment.
Occasionally, we go out and promote MuseScore at music conservatories and we give workshops. Our last workshop in Feb this year was given at the Royal Academy of Music in London.
Currently MuseScore focuses on contemporary notation system. But wasn’t there a project to bring Chinese traditional score support to MuseScore? And then there’s the whole community around early music, partially served by Manuel Op de Coul’s Scala software. Do you see MuseScore adopting more notation systems and tunings/temperaments in the future? How much of a priority would it be?
Nicolas: A Chinese user started an initiative to implement Jianpu in MuseScore, but as far I know no code was written.
Regarding early music, there are some features in MuseScore 2.0 like ambitus, cross measure tied notes, figured bass. In MuseScore 1.3, there was a plugin to read Scala temperament files and apply them to the score. It’s possible since each note in MuseScore can be tuned in 1/100 of cents. I’m sure this plugin will be ported to 2.0 one day.
We also got several requests to incorporate Gregorian Chant in MuseScore, something that the Gregorio Project tackles specifically.
Craig Fisher is working on creating a generic approach to incorporate several alternative music notation systems (more than 5 staff lines, no accidentals, pitched note head etc.) and would like us to incorporate it in MuseScore in the future.
So sure, the demand is here. But again, MuseScore goal is to remain easy to use and to have a broad audience. Not necessarily to attract users with very specific use cases, especially if they are served by other open source software (Lilypond, Gregorio). So we would add more features only if it doesn’t go in the way of a teacher willing to create a simple exercise.
Adding support for tabulatures and importing Guitar Pro files means that MuseScore now partially replaces (or complements — there’s more than one way of looking at it) Tuxguitar for those who have been waiting for its updates for over 5 years. Do you expect it would be sensible to keep MuseScore generic for guitar players and rather see current low-profile development of Tuxguitar to flourish, or do you think there’s a place in MuseScore for more instrument-specific features?
Nicolas: There is definitely a place for more instrument specific features, and especially for one of the most used instrument in the world. The support of tablature in MuseScore 2.0 is quite extensive, but we know we are lacking some features such as harmonic playback or hold bend. These features would be welcome.
Regarding Tuxguitar, it’s a fine piece of software, we used it a lot to debug the Guitar Pro import. I hope someone will resurrect it one day.
During v2.0 development cycle, you adopted Bravura open font and the SMuFL initiative by Steinberg. Have you seen much benefit from this yet, or do you expect to get a better understanding how it affects your user base now that v2.0 stable is out in the wild?
Nicolas: The previous version of MuseScore used a single music font. There was no way to change this font. SMuFL defines a code point for thousands of music symbols together with best practices to create fonts, to define metrics etc… This is incredibly useful.
Once we modified MuseScore to follow SMuFL and integrated Bravura, it was very easy to add support for Gootville, the third font available in MuseScore 2.0. It would be equally easy to add more fonts.
The missing feature is the ability to use an external SMuFL font. If we add this feature in MuseScore, score files will not be portable anymore since the recipient of the score will need to have the same font. The score font being central in the drawing process, the score would look very different if the font is not present.
We will see if the ability to use more than three fonts provided by MuseScore is a popular feature request.
Earlier you established a plugins system to enhance MuseScore’s feature set by getting 3rd party developers involved. Currently plugins need to be manually downloaded, installed, and updated. Some of the plugins only work on Linux, and, as you mentioned, some of the plugins need porting to work in newer revisions of MuseScore. Do you have a plan to simplify this?
Nicolas: For MuseScore 1.x, there are over 80 plugins developed, and indeed they need to be downloaded and installed manually. Sometimes the installation is not trivial and requires admin privilege.
In MuseScore 2.0, we don’t have yet an integrated plugin manager, but some work has been done to make the installation easier. First, there is a way to install plugins in a user directory, and then we have a system to update languages, developed by a GSoC student, which is flexible enough to handle plugins. So, a connected plugin manager could happen in the future.
MuseScore 1.x had a plugin system based on QtScript. In order to create UI, plugin developers could use Qt ui files. This system imposed that we built a C++ bindings for all the Qt classes we wanted to use. This is similar to the plugin framework of Amarok 2.x. For MuseScore 1.3, this binding took 60% of the building time, and so it was a drag. Also, the binding generator has not been ported to Qt5, and QtScript will be deprecated in Qt 5.5 apparently. So we needed another solution.
MuseScore 2.0 scripting framework is based on QML, and so UI can be designed with QML as well. The integration with the core is a bit less painful than with QtScript and so the framework exposes a lot more elements. However, the plugin framework in 2.0 is far from perfect, in particular creating elements is not very developer-friendly, and it would need more contributors.
MuseScore source code evolved/evolves organically and so it’s pretty hard to define a non moving API for Plugins. If this doesn’t exist, it makes less sense to create an easy way to download/update plugins.
Your recent collaboration with Royal Institute for the Blind in London resulted in creating tools to make more sheet music accessible to visually impaired and blind musicians via MuseScore, as well as providing support for the free NVDA screen reader. Last Friday you participated in UKAAF conference to demo these new features. What feedback did you get?
Thomas: Our collaboration with RNIB started in 2013 when they reached out to us with the request if MuseScore could create Modified Stave Notation (MSN) scores. MSN is basically a set of engraving rules which MuseScore users can follow to create sheet music which is easier to read for visually impaired musicians. Enlarging the normal sheet music offered through retail simply does not solve the readability problems. MuseScore 2.0 has now complete MSN coverage and it’s the only package on the market offering this.
The collaboration continued in 2014 with improving accessibility in MuseScore. As this is a real challenge for graphical software such as MuseScore, we limited to scope to the case of verbally reading scores by integrating with the open source NVDA screen reader. And with great results as now the MuseScore menu, most popup windows, the palettes and the actual score view are accessible. This means MuseScore can verbally read all the elements in the score for you via NVDA.
The first feedback on the accessibility came in early January this year. First through James Risdon, music officer at RNIB, followed up by external testers. We learned that technically everything was working, but there were two main aspects to improve on:
- The score reading is too verbose as it reads all what is printed in the status bar.
- The use of shortcuts to navigate through the scores and reach the elements is too confusing.
Both issues are currently being tackled.
As for the real feedback from the attendees of the UKAAF conference, well it’s still too early. MuseScore 2.0 was released just recently and it’s with that release that we expected some more external feedback. In any case, needless to say that being able to verbally read the score is a serious milestone as this was not possible out of the box with no other notation software. So in general MuseScore is leading the way on making scores more accessible.
One notable trend in comments about MuseScore mobile apps is that people expect to be able to use it to compose music, not just read and playback score. Is this something you intend to implement? Would that require smth like iRig Keys support?
Thomas: We did our first baby steps on mobile in the past two years with a player app. We needed to learn how this all works, how MuseScore core could be ported on mobile platforms. We really felt that tablets are the perfect tool to learn new songs, rehearse and perform but less to compose or notate.
When we released the MuseScore apps, we anticipated that quite a lot of the MuseScore users would expect it to be an editor. For that reason, we originally named the app “MuseScore Player” to set the expectations.
Also, we made it clear in our announcement that with this app we wanted to focus on music learning and practicing first. After all, there are quite a lot of people using the MuseScore desktop application for that reason only, so not to notate but to learn.
With the many requests though we have been tempted to test a few things with score editing on touch devices, but we decided to hold off and learn more first about developing for touch. We nicely replied each request that one day we’ll get to it, but first things first.
Adding MIDI support to work with iRig Keys, both in and out, is obviously something we could do as well. There is however no turn key solution available in Qt so we would have to build it ourselves.
With musescore.com (seemingly) fully operational, and MuseScore Songbook app for Android/iOS available for a fee, would you say that the project is financially sustainable at this point? What do you tink should/could be improved? Where would you take MuseScore further in that regard?
Thomas: We launched musescore.com by the end of 2011 and the mobile apps for Android/iOS were released in May 2014. Our goal is to make a vertically integrated platform for sheet music, so providing tools and services for producing, distributing and consuming notated music. That’s all economical lingo just to say that we want to help people to learn to play their favorite songs on their instrument.
One of the major struggles aspiring musicians face is finding the right piece of sheet music which fits their needs. The established sheet music companies have not been able to fill in this demand because their business model is based on scarcity. This is exactly the problem we’d love to fix with MuseScore. So with that ambition made clear, it’s fair to say we are a long time away from being sustainable.