Update on MuseScore 3.6 and 4.0

• Nov 4, 2020 - 16:45

Hello everyone.

The 'internal' team have been pretty busy over the last few months. There has been a lot going on, some of which I'm not quite able to speak about yet but which is very exciting (watch this space!). However, I'm now in a position to be able to explain in more detail what our plans are for the upcoming releases of MuseScore (3.6 and 4.0) and how we'd like to work with the community in future.


To begin, let me discuss our original plans for MuseScore 4 and how they've changed. When we started, we had a few key goals:

  • A new audio engine that supports VST
  • A new interface with a vastly improved user experience
  • A new 'sequencer' mode
  • Better engraving

As we began working on all of these features, a few issues became apparent.

  • Working with the existing codebase was slowing us down significantly and we battled with instability constantly
  • Trying to overhaul our engraving engine while creating a new sequencer - all as part of one gargantuan release - was not a good idea and would take years
  • There were plenty of sensible engraving fixes that we felt should not have to wait until the release of MuseScore 4. This was the most commonly expressed view when we announced MuseScore 4.

After discussing these points at length, we decided to do the following:

  • Rearchitect the application from the ground up to vastly increase our development speed in future (more about this in the next part)
  • Delay the sequencer mode until a later release of MuseScore 4
  • Bring forward key engraving improvements and release them in MuseScore 3.6 instead

That brings me to...

MUSESCORE 3.6
(the release that was never meant to be)

--

This version of MuseScore has been created in close collaboration with our developer community, most notably, Niek van den Berg, who has produced an enormous amount of great improvements. This will also be the first release featuring work by our new engraving expert, Simon Smith (@oktophonie). The ambition for 3.6 is to improve MuseScore's default engraving settings. Here are the most significant changes:

Automatic instrument ordering
From now on, when you add instruments to a score, they will be arranged according to the standard conventions of your chosen genre. From talking to many of our users and studying much of the material on MuseScore.com, it became evident that this was something we needed. It is especially helpful for new users starting out on their compositional journey. This does not prevent you from customising your instrument ordering in any way you want.

Automatic instrument bracketing
This is an important convention that greatly improves the presentation and legibility of scores but is often overlooked by less experienced users. We felt the absence of this default put MuseScore's output at a disadvantage compared to the default behaviour of other applications. For young students, this is an essential fix. For experienced users - especially teachers - it is a useful time-saver.

Our new default text font
Until now, MuseScore has used the font 'Free Serif' (a Times New Roman clone) for titles, lyrics and other text descriptions. Although Free Serif has a very impressive character set, we felt it was time for a significant upgrade, and have introduced a new font based on the classic typeface 'New Century Schoolbook', favoured by publishers like Boosey & Hawkes. The name of our new font is Edwin, named after Edwin Ginn, the American philanthropist who originally commissioned New Century Schoolbook. We will continue to use Free Serif for languages that are not yet supported by Edwin

Our new default notation font
Probably the most significant change in v3.6 is that MuseScore finally has its own notation font! This has been the result of a long collaboration between myself and Simon and I'll be releasing a video about it to coincide with the release of v3.6. In the video, I will describe where our inspiration came from, how we created it and what it is called (honorary points for anyone who guesses. Hush to those who already know). Apart from an entirely new set of symbols, we have also spent a lot of time tweaking a myriad of subtle spacing settings to make it as legible and beautiful as possible. Combined with Edwin, we are very happy with the result!

Automatic vertical justification
If there is one thing that most clearly identifies sheet music prepared in MuseScore, it is probably the presence of a large empty gap at the bottom of the page. This is something we see on MuseScore.com consistently and it was long overdue for a fix. Scores created in 3.6 will now automatically find the most aesthetically ideal vertical spacing to accommodate your music.

Improvements to tremolos and buzz rolls
This was a welcome engraving improvement developed by our community member, @Howard-C.

The ability to apply default settings to older scores
Users can open scores created in older versions of MuseScore and apply all the above defaults to them.

We are currently testing the above changes and you should be seeing a release candidate by the end of November. We would greatly appreciate feedback on our new engraving to help us with the official release, which will hopefully be ready soon after.


MUSESCORE 4.0

A large part of our work for MuseScore 4 has been on 'under the hood' improvements. To that end, our codebase has been completely re-architected and we are porting all our UI to QML. We decided to take this step when it became obvious how slow and painful it would be to try and build a new audio engine and UI interface in MuseScore 3, which, among other things, is plagued with stability issues. Think of this as taking a step back in order to take two forward: it is necessary to modernise and rationalise MuseScore's codebase to greatly speed up our development in future.

Apart from that, there will also be a lot of new things in MuseScore 4. The most important of these is our new audio engine, which will now support VST. The first implementation of this will be quite basic, with additional features and controls (namely automation) being added in subsequent releases. We have also made lots of UX improvements too

  • We have completely rebuilt our Inspector, which is now vastly more powerful and easy to use
  • We have created a new Instruments panel which allows you to modify and rearrange instruments in your scores much more easily. In particular, this makes parts much easier to use and modify

We have created a new Home panel which will house all kinds of add ons and resources. For the first release, this will include:

  • Plugins and extensions
  • Video tutorials

We will also have an entirely new look and feel

  • Improved light and dark themes
  • Options to customise the accent colour of your chosen theme

Other improvements include

  • A completely new Mixer which allows you to assign per-channel VSTs
  • A replacement to the Synthesiser, which allows users to assign soundfonts and VST's globally
  • A revised Note Input bar with new buttons for adding tuplets and common articulations, which will help speed up the writing process
  • Workspaces are more easy to use and edit
  • We have created a tab menu to help us to declutter the workspace and rationalise layout. This has allowed us to move publishing functions into a new Publish tab, which we will be expanding in the future.

WHAT WON'T WE BE CHANGING FOR MUSESCORE 4.0?

In order to get the release of 4.0 out as fast as possible, we will be porting over many of our less used interface elements and dialogs directly from MuseScore 3. The plan is to gradually replace these with redesigned versions (built in QML) in subsequent releases (4.1, 4.2, etc.). We will tackle these in order of priority, probably starting with the settings for adding and modifying time signatures (a part of MuseScore that definitely needs a rethink).


HOW WILL WE BE WORKING FROM NOW ON?

Once we have completed the underlying architectural work, one of our major goals is to collaborate more effectively with our community. To this end, we will begin publishing our design plans ahead of time and holding occasional video conference calls. The purpose of doing this is to:

  • Solicit feedback about our designs and processes
  • Inform our community of developers about our long-term plans, so they can confidently work on changes without worrying about potential feature clashes
  • Collaborate on features more effectively. Our work on the release of 3.6 has shown us that this kind of effort can bring enormous value
  • We will also publish some design guidelines to explain the ideal functionality of new components and widgets
  • We will publish technical explanations to help community members come to terms with the new architecture of 4
  • We will also soon begin providing design support to community members to help them with UX and UI considerations. Our ultimate hope is that the future of MuseScore will involve much more closely integrated collaboration between the 'internal' team and developer community.

RELEASE CYCLE

Once MuseScore 4.0 is out, we are planning on moving to a strict 3 month schedule for releases. This way, if a feature is not ready for a given release, there is always another train just around the corner.


WHEN DO WE EXPECT MUSESCORE 4.0 TO BE RELEASED?

On current trend, we expect MuseScore 4.0 to take between 8-10 months to complete.

That's it. Thanks very much!
Martin Keary

Product Owner of MuseScore


Comments

In reply to by marczellm

Is 3.5.2 on Windows Store? If not this needs to be done. 3.5.0 & 3.5.1 were never put on Windows Store due to bugs that needed to be fixed. There is a delay built into the process to prevent too many users from upgrading to a version with a bad bug.

Exciting news!

I know this is low on the priority list, but there is one audio rendering feature which is sorely lacking for bass players: supporting dead notes. Bass lines use them all the time, especially in R&B and funk. I started using musescore in the year before 3.0 came out and have been hoping each release that someone would address it, but patiently I sit because I'm not able to contribute this feature myself.

It is easy enough to mark a note head as a dead note, but in the audio domain one has to choose between hearing it as a rest or as a fully articulated note. There are some hacks to create a parallel hidden staff where a percussive instrument voice is used and for each bass ghost note a parallel percussive hit is entered. But that is a brittle, labor-intensive hack.

Thank you for the post, I was waiting to see what would be mentioned!
Man, all those contributions... I feel like I also want to contribute, that much in the end I might end up studying programming instead of composition or drawing-related stuff.

Every Musescore 3 update is something great and new! Can't wait for everything that comes in the future! But really, the 2 first 3.6 features, seemed minor, I mean it wasn't a big hassle (at least for me) to put the orchestral instruments in the correct order and adding brackets, especially, causes no sweat. But they are cool features nonetheless, for people who like to make everything more automatic and convenient. I love it. eek.

Yes, what makes Musescore great is democracy, I don't mean the vote of the majority, I mean the way that the contributors listen to the opinions of its users and making this community. But what also makes Musescore unique is its epic features and the intrigue (intriguity?) that bring to me that make me want to see what else those contributors thought of adding! Saying thank you is not much, but thank you all.

I wanna test Musescore 4 so badly but it's still too buggy and not ready for testers like me (eek I'm not even a great tester I just wanna see how I'm gonna transcribe my favourite Stravinsky works) so I suppose from what you said I can probably start in 6 months. But I checked the Musescore 4 UI I have no complaint (if you wanted to know). ~~I just hope I will be able to find a way for Musescore 4 to include straight trumpet mute and/or other kinds too~~.

Lots of great news! Very exciting.

>We have completely rebuilt our Inspector, which is now vastly more powerful

Currently when the user changes the score with the mouse the Inspector updates only on mouseUp. I'd like to see an Inspector that updates values on change. Then one could move or resize object and see x/y position or scaling reflected in the Inspector while dragging.

In a similar vein dialogs could afford a more responcing environment. Some dialogs have an Apply button which is a decent option presently, but ideally most dialogs would no longer need an Apply button and would simply update the score as the user edits values, then on OK commit the entered values, or revert them on Cancel.

I always look to software updates--in MuseScore and elsewhere--with a mixture of excitement and trepidation.
In particular: "The ability to apply default settings to older scores." Will it be possible, or simple, to apply some of those defaults to older scores (in my case, the Verticle justification improvements), without appyling others: even tiny changes in music or text fonts will send carefully laid-out scores hopelessly askew.

Also, although I am of a mixed mind about defaults such as automatic score order and bracketing: although it's a time saver for educated composers, it is a mixed blessing for learners: in one sense it ensures that they'll produce better quality notation, but I'm enough of an Old Fogey to wonder whether it does too much work for them--like using calculators in Trig Class (boy am I dating myself!)

In reply to by wfazekas1

I don't know the technical details of how the new settings will be applied, but I would note that even if the "easy" button only allowed for an all-or-nothing application, nothing would stop you from doing it the hard way, going into the various corresponding style settings and set or reset them individually.

In reply to by wfazekas1

The motivation behind this feature was when oktophonie was hired and first looked at scores on musescore.com and so many of them were so badly laid out. He decided something needed to be done to make MuseScore look more respectable.

From my experience with looking at scores on musescore.com and answering questions here, a lot of people learn about music composition from using MuseScore. One common thing people ask about is the tremolo. Most music reading musicians know what a tremolo is. This is anecdotal but I do understand that oktophonie wants scores created with MuseScore to look good out of the box with minimal intervention by the user. We'll see some of this in 3.6 but 4.0 will really start improving the out of the box engraving by MuseScore.

I do understand the calculator in Trig class analogy and at times I think the program is doing too much but then I realize that it allows me to concentrate on other things.

In reply to by mike320

My biggest visual shock was with seeing (some) scores presented as "look what I notated" which were clearly raw MIDI imports - with those crazy (on-off) note timings notated with an incomprehensible (to a human) precision, along with bizarre multitudes of ties stretched over a series of (quantized) notes.
Sounded good, looked horrific.

I'm now curious about what "product owner of Musescore" actually means.

So far I think Martin has been doing a great job, but does he now own the site, or is he a part owner?

It would be pretty cool if a ritardando / rallentando (and accelerando as well, for that matter) lines were added, which would make gradual tempo changes a lot easier. Users could choose what bpm they want the music to shift to after a certain number of specified bars. Just a suggestion :)

In reply to by 5ScorpioCHyxhe

I can second this - but in fairness maybe the future plans are such that those will happen with the next major release. I don't know enough about the "under the hood" workings of MuseScore, but if it's currently possible to simulate the effect of a rit, rall - whatever by using hidden tempo markings and a bit of manual effort, then I don't see that it would be an enormously difficult thing to automate it. There may be a mish-mash of different tools in MuseScore, but if one looks at the pitch bend feature, that has an interface which allows pitch changes over time - admittedly rather short - but similar code and interfaces might work for rits and ralls. There could be default profiles based on the start and end tempi, but other options could also be provided.

Similar automation controls can be provided (they may already be there) for changes in dynamics - e.g. for dim. and cresc., though I have wondered whether those always work well enough in MS. This kind of feature is available in some DAWs.

There is still an argument that MS was never intended to be a dynamic playback system - which I can accept - though I do think that things have now gone way beyond that, and it is sufficiently good and comprehensive that it can do that kind of behaviour as well as being a way to develop printed music.

I won' t push this again for a while - lets give the development team a chance to come up with something good which works.

I also second the big THANK YOU to the development team.

In reply to by 5ScorpioCHyxhe

> "But wouldn't still it be a lot more time-saving if MuseScore added an "actual" ritardando, rallentando, and/or accelerando?"

Sure it would be best if MuseScore did all it ever needed to do and all perfectly ;-) But many things in MuseScore also depend on contributions; meaning that someone needs to come along with the right combination of free time, musical understanding and coding skills to put in the effort in writing something like that.
And it also makes sense that the in-house team focusses on equally (or more) important/pressing issues for which no workaround at all exists.

Do you still have an unanswered question? Please log in first to post your question.