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

Comments

I just downloaded MuseScoreNightly-2016-06-04-0008-master-1daaae1 and when I opened one of my existing 2.0.3 files the first page will not show instrument name long. I go into the instrument edit page and it shows the correct instrument long name. How do I get it to show the long name in first system?

Not specieal for 3.0, it is that way in 2.0 too, but see https://musescore.org/en/handbook/layout-and-formatting#style-edit-gener..., "Hide instrument name if there is only 1 instrument". If is is not that, please share the score, so we can check

Here is the same file in 2.0.3 and nightly version. As you can see when opened in 2.0.3 it shows long instrument name on first page. However, when opened in 3.0 nightly it shows short instrument name on first page.

AttachmentSize
Death Or Glory.mscz 85.47 KB

Indeed, very strange, could you report it in https://musescore.org/en/node/add/project-issue/musescore, please?

Any improvement that changes the relayout time will be a godsend. My larger scores cause 2.0.3 to pause for 5 minutes-at-a-time every 20 seconds or so, to the extent that I give up. This is particularly the case, recently, where I converted a Sibelius score by xml only to find that MS said it's full of corruptions - trying to fix the corruptions with the slow process described is soul-destroying. (I sent the subject file as a PDF to that experimental site that comes up on MS two weeks ago but haven't had a response so far.

For some changes, there's not really much that can be done—for example, if you transpose the whole score, it will still take as much time. But I just checked out one of your particularly large scores (https://musescore.com/user/1394221/scores/1248246) in a nightly build, and the same test (moving the first note up and down) came with no delay at all.

I have no doubt that your nightly test doesn't repeat the problem, however, my experience with MS 2 has been abysmal. The score that you tested was bad enough - I'd get 30 seconds to a minute to make a change and then the program would stall (freeze) for anything between 1 - 5 minutes (that's why the articulations are all over the place). The corruptions that MS found had to be corrected in 1.3, otherwise I would never have been able to do it, on 2.0, without cutting my wrists!

The score that I referred to in my last comment hasn't even been posted - at last count it would take me 20 minutes to fix just one bar! The problems have been worse since I uploaded ".3" (then again, I had an almighty time just trying to upload 2.0. The download would freeze my PC every time I tried to install (I posted quite a lot of comments at the time) until, one day, it worked - just not very well on large scores).

I would very much like to post that last score, which is why I submitted a PDF but, as I indicated previously, I've had no response to that (by the way, the Sibelius score doesn't have any of the defects that MS 'found' as "corruptions"). I'm happy to send you the sib file and/or the MS file if you wan't to try to fix the resulting xml, which came out with heaps of corruptions.

Best wishes,

Mark.

There's a slim chance that the MusicXML file from Sibelius is not actually corrupt, but just slightly nonstandard in a way that causes MuseScore to misinterpret it. But that's not the most likely, and either way, it's Sibelius support you want to try to contact (attaching the SIB and MXL files) to figure out what's going on with the files they're generating.

Oh my god! I can't wait to download Musescore 3.0! Thank you!

Slow down! Right now, there is no MuseScore 3.0. I'm afraid you do have to wait for that. We're just beginning to work on it, that's all. ;-)

Wow, I dint know that closing the navigator speeds up Musescore. Thanks for the tip! (Are there any other ways that you can speed up in Musescore 2.0.3?)

You're welcome! The other thing, as mentioned above, is don't generate parts until you have to.

Thanks.

I have also found that editing in continuous scroll mode slows it down, sometimes to the point of stalling. And that's on scores of just 8 to 10 pages... a little big, but not extremely big. I had to go back to editing in page mode which has other disadvantages.

Wow! I'm looking forward to trying it out when it comes out. It's been a while since I've tested the nightly build.
When I was seeing the difference in times, I was trying to remember the time lag that humans have. (I think it's 80 milliseconds). I wonder how that's going to affect the way I perceive MuseScore's behavior.

how about musescore 2 files backward compatibility? are they supposed to work out of the box? I remeber that switching from ms1 to ms2 most of my old sheets losed their layout, position of lines, altered beams etc.

layout changes are to be expected, when loading 2.0 files in 3.0 vs. openening them in 2.0

will there be a plugin to import v2 to v3? not essential, but would be nice! thank you for reply!

Why? So far 2.0 plug-ins work in 3.0 too

I'm guessing he means a tool to convert 2.0 scores to 3.0 scores.

3.0 surly will read 2.0 scores

To take advantage of 3.0's new features, though, one would have to make a new score.

Or just save the 2.0 score once with 3.0. Same as with 1.x scores in 2.0

Syndicate content