Insanely slow score editing on Musescore 3

• Dec 29, 2018 - 23:19

Hello, I have ran into several issues with Musescore 3, primarily low performance. My system is more than enough to run Musescore (i7, 16Gb DDR4, GTX950), yet, note input always takes more than 1, maybe even 2 seconds from intent to result. I have navigator closed and only have inspector/palettes showing. I am beginning to become frustrated as to why this is happening, so any input would be appreciated.

Attachment Size
Scheherezade MOv 4.mscz 97.14 KB

Comments

• Dec 29, 2018 - 23:24

I also have this (raised here but not really addressed, or people aren't having the same problems as us: https://musescore.org/en/node/280716)

The whole editing is very slow on a larger file - adding a dynamic sign takes almost a second, and selecting a note and pressing the up arrow button three times takes probably 3/4 of a second to move and play each note before it reaches the top note. This action was pretty much instant in v2 with the same sized file.

v3.0.0.4875, Windows 10, Asio4All audio driver if that makes a difference.

Reply

• Jan 25, 2019 - 19:29

Hello! I believe I have the probable answer to this if you haven't already gotten one. I was having the same problem for ages until recently I FINALLY figured out what MY issue was. So just follow with me,

  1. Is the score large (In terms of instruments, like, concert or marching band or just lots)
  2. If yes, is it split into PARTS?
  3. I found that when split into multiple parts that my score would slow significantly, and here's why.
    Basically, every time you make an edit, it has to reorient every part, this causes heavy usage on the program and makes it lag. I started waiting until I was done to split, or I just would delete parts after I was done (If I split to work on individual things)

So, in a nutshell, if you have parts, get rid of them for as long as you can.

Hope this helps!

-KA

Reply

• Dec 29, 2018 - 23:55

I agree, MuseScore 3 gets slow, way too fast, and it shouldn't. It's advertised as faster than version 2, but I haven't seen any improvement. A string quartet created from scratch in version 3 starts getting sluggish at about 150 measures.

Reply

• Dec 31, 2018 - 01:10

I did some experimenting with the newest version of Musescore 3 up to this point, and it seems like the fastest way to make edits is to get rid of the navigator and use the normal page view. Even the new single page view ran significantly slower, which to me makes no sense. The continuous view runs the slowest by far.

If you want to edit your scores without any delays, then you're going to have to do some hard work. You'll have to make a new project for every sheet you add to the score. Then, when you're 100% positive that your score is as good as it will get, combine the projects into one project, and there you go. I know it sucks, but that's the only way I see that can speed up editing. This is true for all versions of Musescore.

Reply

• Dec 31, 2018 - 01:23

My method for dealing with slowness is to create an empty "temp" score with about 50 measures or fewer. I break the score into short passages that are a page or the shortest length after that where there are no slurs, ties or other lines across measures. I use that to enter everything that isn't a system item. System items include things like Tempo, key signature, time signature and I'm probably missing one or two important things like Rehearsal marks. I enter my score into that, then I paste it into the "real" score and enter system items. I actually enter tempo changes in the temp score, select only the tempo change copy and past it into the score since editing text is one of the most excruciatingly slow things you can do.

I always use continuous view to enter scores, and I've found that after about 75 measures of a symphonic score (35-70 instruments) Musescore 3 slows down to the point I would rather copy and paste, but it doesn't become impossible to work on until about 125 measures. The number if instruments makes some difference, but the number of measures affects it more. The string quartet I'm working on becomes rather sluggish at about 125 measures.

Reply

• Dec 31, 2018 - 21:41

From what I understand about how this l works, the speed advantages of 3.0 WOD not work well in Continuous view, because the main premise is to only relayout systems that need it, and in Continuous view, the whole score is one system. Maybe there is more to it than that, but on the surface I would not expect to see any speed advantages in Continuous view, only Page.

Reply

• Dec 31, 2018 - 23:12

Continuous view should logically be faster. There is little layout prior to the current position to think about. There are no pages to calculate, no staves being moved to make room for anything, no avoidance of dynamics etc..., what would slow down continuous view?

This main problem with page view is that the when the cursor moves to the next page, it's almost always impossible to see the last note entered and the view does update nearly every item entered. For untalented people like me, I can't see that I pressed the correct key and adding chords and articulations to this note is cumbersome. I would sacrifice the speed of changing to page view while MuseScore does all of its auto avoidance calculations to get faster input in continuous view.

Reply

• Jan 1, 2019 - 01:27

I'd bet that what slows down continuous view is exactly what I said - the fact that the main optimization performed is only laying out the current system, but for continuous view, current system = entire score. So the "only layout what is needed" fails to make a difference, because "what is needed" is everything. That's my assumption. It fits both the explanations given of how it works as well as the observed facts.

Reply

• Jan 1, 2019 - 14:49

Curiously - I use 2.3.2 I have 4GB RAM with 4GB more coming in the mail. Does more RAM help with speed?
Also -
About continuous view: as useful as it is, I've noticed a fault. One example: In a piano score, when returning back to page view,all those ped__* markings all over resemble Tom Landry's flex defense...one must trolley over to the inspector to straighten the lines and then hope that Save means "Save".

(I love MuseScore...I hate toil.)

Reply

• Jan 1, 2019 - 11:27

FYI, trying the big score "Thunderbolt" listed in #280952: Score Editing Slow and changed one note and was curious to see if it was wasting time in other pages other than the one being edited...so I put breakpoints around LayoutContext::collectPage() and found that it indeed is spending typically 500ms for every page*, some more than that. So it seems somehow the goal that a single minor edit wouldn't cause time to be spent in other pages seems to have failed. I haven't investigated.

*(I'm in debug mode at the moment...unfortunately with precompiled headers it isn't easy to switch between debug and relwithdebug...if anyone has tips on how to easily switch configurations in msvc, that would be nice.)

Reply

• Jan 25, 2019 - 19:27

Hello! I believe I have the probable answer to this. I was having the same problem for ages until recently I FINALLY figured out what MY issue was. So just follow with me,

  1. Is the score large (In terms of instruments, like, concert or marching band or just lots)
  2. If yes, is it split into PARTS?
  3. I found that when split into multiple parts that my score would slow significantly, and here's why.

Basically, every time you make an edit, it has to reorient every part, this causes heavy usage on the program and makes it lag. I started waiting until I was done to split, or I just would delete parts after I was done (If I split to work on individual things)

So, in a nutshell, if you have parts, get rid of them for as long as you can.

Hope this helps!

-KA

Reply

• Mar 9, 2019 - 01:07

Same problem over here...
It's really slow moving elements. Really slow.
Not like MuseScore 2.3.2.
I'm very dissapointed
Just installed MuseScore 3 today. But it's really slow :/
If curious:
4GB RAM - AMD A4-6400 APU with Radeon(tm) HD Graphics of 3.70 GHz
500,000,874,496 (500.8 GB) ROM
Windows 7 Professional
with x64 OS

Reply

• Dec 22, 2020 - 20:44

Sadly enough, I have to confirm that the downloadable AppImage of Musescore 3.6.0 development version and also the previous version is unworkably slow (on Ubuntu 18.04 with KXStudio on top). Everything stall constantly with everything I do, selecting Navigator view or whatever. Absurd. Even more absurd is that it totally blocks my soundsystem (Jack). It blocks pulseaudio and I cannot play any music any more and that is not normal. The great advantage of Jack is (with the Alsa and Pulseaudio bridges) that I can connect anything and nothing blocks each other. This version does and more annoyingly, it makes that my soundsystem on the regular Musescore install (not the AppImage but installed from repository) does not do anything anymore. And I cannot even restore the latter. When is this going to work without trouble for once, I wonder? I desperately need a good working system and I cannot have a development version ruin everything. I'm even considering a completely new install of everything, not knowing what causes it (I removed the .ini files and even installed musescore again, but nothing helps)

Reply

• Dec 23, 2020 - 13:18

Just as a sidenote: be aware that the “AppImage [provided] by MuseScore” is illegal to distribute at all, even for MuseScore, because it contains OpenSSL and GPL-licenced code linking against OpenSSL. (I can probably find more licence violations in it if I look.)

 — slightly disgruntled packager

Reply

• Dec 23, 2020 - 13:19

Gertim, in case you haven’t still blocked me for our mutual misunderstanding about that Haydn piece, I’d be willing to try and help you (e.g. via some chat) to install the packaged version of MuseScore 3 again (after having uninstalled the AppImage, although they should in theory be able to be used alongside and not conflict with each other).

Reply

• Jan 17, 2021 - 11:44

Block you? By no means. The App Image (3.6.0) is still enormously slow. Opens slow, loads slow and when applying something I have to wait long before I can go on. Saving lasts long. It is basically unworkable for me this way (it has nothing to do with large scores; it does it one page scores as well). I would like to have it installed through the repository, because that seems to work much better (I don't have this problems with Musescore 3.2 installed through the repository at all; i saw you delivered that one as well).

Reply

• Dec 24, 2020 - 17:20

I would note, though, that none of what you describe sounds normal - that is, we have many thousands of users on Linux, and none have reported anything like what you describe. So my guess is there some some specific issue with a specific driver or configuration on your system. Unfortunately, I have no clue where to start looking.

Reply

• Jan 17, 2021 - 11:50

Maybe others don't mention it, but that does not mean that others would not have the same problem. Maybe others are still using the older version and I'm the first to tell (or that they keep using the installed version, which does not have the problem). I noticed before that the App Image is substantially slower than the regularly installed one. After a while of use, it seems to become a bit better, but then all of a sudden it is slow again (certainly when closing and starting it again).

Reply

• Feb 4, 2022 - 01:17

Hi just ran into the same problem, however, I fixed it for myself and this might work for you. When you make a new score don't use the template. Add each instrument individually. Click on new, add title information, choose treble clef, choose key signature, choose time signature, and click finish. Your empty score should be displayed with only one instrument. Now, select Edit and within that menu choose Instruments. Add your instruments. Once I did this it ran smoothly and quickly on my machine. If you already have a large score created you will want to copy and paste your notes over to the new one. Hope this helps.

Reply

• Feb 4, 2022 - 23:48

Hmm, there's no reason using a template versus creating from scratch should affect anything. Most likely the score you were having trouble with had become corrupted somehow, so starting over with a fresh score was really what fixed it, not the fact that it was created instrument by instrument rather than with a template. But if you still have the slow score, I encourage you to attach it here so we can investigate.

Reply

• Feb 5, 2022 - 04:09

Well I can't post the score since I deleted and HAD to restart but I can tell you what it had. Four half notes and 10 bars. Each bar had four half notes and nothing. For as the somehow got corrupted part isn't really something for me to look into. And if a score gets that corrupted at the start maybe some rework with the software might be needed because placing notes should not be that demanding.

Reply

• Feb 5, 2022 - 21:19

It normally isn't. but once every million or so scores, problems where somehow a score ends up having tons of duplicate slurs or other elements has been known to happen, and then you end up with a score that is much larger in actual file size than it should be, and it's also slow to work with. We've fixed the bugs we know of that lead to that very rare situation, but it's possible either your score was created with an older version, or there is some even more rare bug still remaining. So that's why we'd need to see the score itself to see if that's what is in fact happening. If so, then next step would be to try to understand how the score got into that state. Or if that's not it, to try to understand what else might be happening to make the editing slow on that particular score. If it turns out we can't reproduce the problem, that tells us the issue has something to do with your system in particular - maybe some other software on your system causing a conflict. And then we can help you diagnose that. Or if we can reproduce the problem, we can take it from there and investigate what is going on and how to fix it.

So, if it ever happens again, be sure to save the file in the state where things are slow, then come back here and post it (or start a new thread), so we can understand and assist better.

Reply

• Jun 14, 2022 - 23:08

I found the reason for the slow editing in continuous view mode: the Navigator feature (View>Navigator)
When enabling the feature, editing becomes a wagon, with motion lags, including insertion of notes, and text. Just disable the navigation bar, and the problem disappeared.

Reply

• Feb 6, 2023 - 17:29

Thanks for this. I found that I can use the navigator without performance penalty provided I give it a bit more height by dragging the top of its frame upwards. I'm guessing it might be something to do with difficulty generating the 'thumbnail' pages for the navigator when the size ratio is too great.

Reply

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