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

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.

In reply to by GoldmanT

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

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.

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.

In reply to by Commander Continuey

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.

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.

In reply to by Marc Sabatella

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.

In reply to by mike320

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.

In reply to by mike320

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.)

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.)

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

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