Developing MuseScore 3.0: MuseScore gets faster

Part 2 of 3

MuseScore 3.0 is currently under development, getting ready to be smarter, faster, and easier than any previous version of the world’s most popular, powerful, and easy-to-use free and open-source scorewriter.

In last month's blog post, we outlined our development goals regarding the first of those three main areas of improvement, which we’re calling Smart Layout. Now, here’s an update on one of the other two main points: how much faster the next major version of MuseScore is going to be.

In all versions of MuseScore so far, every time any edit is made, the positions of everything in the entire score from beginning to end are recalculated in a process called relayout. You’d never notice it when working with a relatively small score, but a few dozen pages, and the delay after every edit starts to become appreciable. The problem compounds itself rapidly if you add linked parts, as the edit then has to be reflected through each part; and it’s much worse if you have the Navigator open, as that’s basically a whole other score view.

In general, the larger and more complex your score, the more likely this complete relayout with every edit is going to start making MuseScore slow.

As with the problem of score elements overlapping each other that we discussed last time, this has come up again and again on the forums. The problem is real for any large project, and the MuseScore team has made it a priority for the development of MuseScore 3.

MuseScore 3 will be just as fast no matter how big your score is. Only the page on which the change was made will be recalculated, while the rest of the score, which can safely be assumed to be the same, will not be involved in the relayout. (If a change on one page results in the page breaking in a different place—i.e., also changing adjacent pages—then any affected pages will be laid out again, as well, but no more than necessary.) While linked parts and the Navigator will still slow things down, the relayout time for most edits will be entirely independent of the score size.

The difference in speed is staggering. Here’s a taste of how good it is:

Test

Moving the first note in Bach’s Goldberg Variations (990 measures, 58 pages)
Windows 8.1, Core i7-3630QM, 2.4GHz., 16GB RAM

Result

MuseScore 2.0.3 (compiled with Qt 5.4.2):
    220 milliseconds (complete relayout)
MuseScore 3.0-dev (compiled with Qt 5.6):
    1.5 milliseconds (single page relayout)

As the Goldberg Variations score is so large, that tiny edit comes with nearly a quarter-second delay in the latest released version of MuseScore. But the 3.0 development version already handles it more than a hundred times faster. That’s virtually instantaneous response time.

There are great things coming down the pipe. Again, as stated in the last post, MuseScore 3 is not anywhere close to ready. However, the very haziest outlines of what MuseScore 3 will be like are available for testing in the nightly builds. There is no guarantee anything will work. Let Werner Schweer warn you:

  “It crashes very often currently, and does other bad things.”

So let’s fix that! You can help us develop MuseScore 3.0 by testing the latest features in the nightly builds, and reporting the problems you encounter. Your feedback is very welcome in the Technology Preview forum, and precise bug reports can be directly posted in the Issue tracker. If you’re a programmer as well as a musician, we would appreciate your help fixing the bugs—as MuseScore is free and open source, anyone can get the source and share code contributions on GitHub. You can also support the MuseScore 3 effort in the simplest way with a donation.

So, now you know that we’re making MuseScore (1) handle overlapping score elements intelligently, and (2) process edits lightning fast.

Next time: MuseScore gets even easier