Our Progress on MuseScore 4
I wanted to give a general update about the remaining work left on MuseScore 4. We've recreated most of the new interface and functionality now and have ported over most of the MuseScore 3 functionality too. Now we feel it is possible to begin mapping out a draft release schedule, although there are still some large chunks of work that are hard to estimate so this timeline may change (hopefully by getting shorter!). In addition, I want to describe what aspects of the application we are planning on delaying until a future release (4.1, 4.2, etc.).
The single largest piece of remaining work relates to playback. First, we are replacing the Zerberus sampler/synthesiser with a new (much better) playback system that we have been developing. This will not be packaged with MuseScore but can be downloaded and activated (for free) once the application has been installed. Until the user installs our new system, the default player will still be the soundfont currently packaged in MuseScore 3. We will create a separate detailed post about this shortly.
Since we have implemented VST3 and VSTi3 support, this has necessitated an up-licensing to GPL3. As a consequence, the old reverb and limiter effects (Zita & SC4) will need to be replaced with new VST effects instead. For now, when installing the new MuseScore library, we will also download and install two of our own VST effects to make up for this. Since we are only beginning on our VST journey, there will be many opportunities to integrate compatible VST and VSTi plugins in later releases.
We will be removing the 'Synthesiser' panel entirely from MuseScore and building some of the functions it served (ordering sounds and library priorities) into our new Mixer. For 'master' FX, we will be creating new auxiliary channels in the mixer, where the reverb FX will be situated. We will be saving user preferences relating to playback (VST settings, Aux channel settings, preferred libraries, etc.) in our project files and will be removing the concept of 'Save to Score' and 'Load from Score'. Instead, we want to develop a system for efficiently switching between projects that have different playback settings.
We are aware that it can be difficult to determine which parts of MS4 are 'finished' (but still have optimisation bugs) and which parts are just incomplete. We are going to start marking these different strands of work clearly to help the community understand where they can feel free to optimise and improve functionality and where they can expect more changes to appear. The terms we are thinking of using are:
Incomplete (the designs have not been fully implemented)
Feature Complete (requires optimisation)
Release Ready (no optimisation required)
To give two examples (at the time of writing): Our new 'Note Input Bar' is Feature Complete: the designs have been full implemented but there are a few bugs. For example, when redocking the bar, the ordering of the buttons can become mixed up under certain circumstances. Community members can feel free to optimise this part of the app without worrying about new changes occurring which might cause conflicts and headaches. We constantly review bugs and publish them on our GitHub Projects page.
The 'Inspector' however is Incomplete: there are some parts where the designs have not yet been fully implemented and there is still some significant clean up work to do. In this case, I'll be publishing a new specification highlighting what remaining work needs to be done. In all cases: if community members want to take part in helping to complete work marked as Incomplete, Peter Jonas (our community manager) and I can work closely with you to hash out the details and make sure no work is lost.
Peter will shortly be publishing a general list that outlines the status of each chunk of work shortly. Peter also holds regular live build reviews on our Discord server, where this can be discusses in person.
Below is our draft plan for releasing MuseScore 4. Note that marketing and automatic updates will not be switched on until after we are satisfied that the application has no remaining large issues.
(See the link below for a higher resolution version)
As announced last year, we decided to delay the sequencer view until a future release. This was a decision taken to enable us to work on a new playback library instead. Regarding the features from MuseScore 3, the main component we are also considering delaying is the piano roll - simply because it is gargantuan in size and because we also want to completely redesign and reimplement it. This is particularly painful because the addition of VST support will make the velocity controls infinitely more desirable and useful. However, we have estimated that porting over the existing piano roll (and incorporating into the new codebase) will delay the MuseScore 4.0 release by up to two months, which we feel is a step too far for a control we ultimately want to replace. This is not to dismiss the wonderful work done by Mark McCay (and others) on the MuseScore 3 piano roll. It is simply an awkward timeline issue.
As a backup plan, we are going to create a very simplistic design for a new piano roll, which will only contain the feature that allows users to edit velocity and expression settings. We are going to open up this design in case any community members wish to build it. We have also added this as a Google Summer of Code project, although it is unlikely that the outcome will be a feature that will be ready for MuseScore 4.0 due to the limited number of hours that GSoC students have to work with.
In the instance where there is no piano roll in MuseScore 4.0, users will need to edit velocity settings using the inspector, as in MuseScore 3. Don't worry though. The piano roll is a vitally important feature, which we are going to prioritise once MuseScore 4.0 is released.
After the release
The best thing about MuseScore 4.0 is that once we've built it (with its new architecture, playback engine and UI), we'll never have to build anything so massive ever again. We then intend to move to a steady release cadence, so we can gradually build up feature improvements in a more manageable and transparent way.