Musescore 3 running very slow

• Feb 19, 2019 - 03:45

it's been happening for a while now, but it's worse then ever. when i type in the note they usually appear about 10 seconds after i've typed them in. it's even longer, maybe 15 -20 seconds when i try typing in the score title and subtitles. and when i do things such as change time and key signature, it usually crashes. any help?

Comments

• Feb 19, 2019 - 18:03

I'm experiencing the same thing. Anything I do in any scores I open takes about five seconds to appear, whether it be putting time signatures, adding lyrics, or even just inputting notes. It's like playing on MineCraft servers. MuseScore 2 was definitely not as slow.

Reply

• May 14, 2019 - 03:01

I'm having the same problem. Musescore 3 is so slow that I can't even use it with my students during class any more. I'm wondering if it could be a soundfont issue, because I don't remember this problem before I began using my custom SFZ for certain projects (which is only 731KB so definitely not a memory drain). However, it's running slowly even when using only default sounds. Is there anyone from the Musescore team who can comment on this thread? Any help would be massively appreciated! Thanks in advance. -May 13, 2019

P.S. If I discover anything, I'll be sure to post about it.

Reply

• May 14, 2019 - 03:28

Just confirming that everything still works great in Musescore 2. Soundfonts, music xml imports, and everything. Playback is smooth. Entry and edits are all snappy. Musescore 3 is now unbearable. I have no idea what the problem is, but it looks like I'll be parting ways with Musescore 3 until I can try another update -- unless someone has experience with this problem and knows how to fix it. Thanks, and good luck everyone!

Reply

• May 15, 2019 - 02:16

Can you explain which specific actions are slow? And/or post a specific score and precise steps to reproduce the problem? Other than editing in continuous view - which I'm having some success improving - everything should in general be faster (considerably so, actually) in MuseScore 3.

Reply

• May 15, 2019 - 03:38

Excellent! Here is a link to the most recent Windows build (sorry, not available for other OS's yet) if anyone else would like to help test:

https://ci.appveyor.com/api/buildjobs/hd6a5scw6l3ivapv/artifacts/MuseSc…

But I would note this would only be about editing speed, nothing about playback. I can't think of anything in particular that would cause playback problems in 3.0 although I know there have been scattered reports of issues that have proven hard to reproduce, and also that some improvements were very recently made in that area.

Meanwhile, if anyone does test out this build, I'm especially interested in any layout glitches you see - cases where edits to one measure in continuous view cause unintended side effects in other measures, like beams or slurs disappearing or becoming separated from the notes they are supposed to be attached to.

Reply

• May 16, 2019 - 05:01

Thanks so much for your response. I've done some experimenting and have more information:

Musescore 3 (for me) runs very slowly regardless of edit mode or display mode. It exports slowly, plays back slowly, navigates the score slowly, selects/changes notes slowly. Everything is super slow, EXCEPT clicking in the shell menu. The file | edit | help | etc... all seem to be unaffected; although many of the functions that they trigger are. A few specific examples:

  • When I change a keyboard shortcut then press okay, it takes 24 seconds before it finishes. I've timed this 4 times, and it's consistent, no matter the size of the score.
  • When I press Spacebar to play, nothing is drawn to the screen for a few seconds, then it jumps around, updating once or twice per second...lagging a few beats behind.
  • When I enter a tuplet on a brand new score, it takes about 2 seconds to update (even on a brand new score with no other notes and only a few staves).
  • When changing levels in the mixer, I can't move the sliders in real time. It takes several seconds before I can see the change that I made reflected on the slider or in the audio. Sometimes as much as 5 seconds.
    • When selecting notes, it sometimes selects and plays immediately, but usually it takes a second or 2 per note, even on a new score. If I switch back to musescore 3 from another program, the first note I click loads immediately, but each note after has substantial lag. This is consistent.
  • When trying to pan, it takes musescore a few seconds to catch up to mouse movements and start moving the score. So I have to click and hold, then move slowly until the score begins panning. Once it's panning, I can move faster, but it's still somewhat laggy. Maybe 8-12 fps.

All of these problems and more exist even with a clean install of musescore 3.0.5.5992 and 3.1 beta. None of these problems occur in Musescore 2.3.2.

When I first installed Musescore 3 (back in February), I didn't have any of these problems, so I have no idea why this has been happening for the past few weeks. I first noticed it when I was using musescore in class (I teach music) about 2 weeks ago. I plugged my laptop into HDMI, booted up my projects, and noticed that musescore 3 was unresponsive for several seconds. I couldn't use it for class, but we could at least load our scores in. I thought maybe it was HDMI audio, so I didn't think much of it. But now, it's clear that something is seriously wrong, and I am flabbergasted.

I'm running Windows 10 Home edition on a MSI GS65 Stealth Thin laptop, if that helps. I thought maybe it's an audio driver issue, but that wouldn't explain 24 seconds to change a keyboard shortcut or major lag when panning the score. It also doesn't explain why Musescore 2 still runs perfectly. This is really weird.

Reply

• May 16, 2019 - 05:57

runs very slowly regardless of edit mode or display mode What does this mean? Edit or display mode? Those terms don't exist in MuseScore.

In general, page view is fast and works well as long as you don't need too many staves displayed on the screen at once. Continuous view slows down to a crawl and becomes unusable rather quickly, especially when there are a lot of instruments. I'm currently testing the fix I linked to above and it's better than any released version. I'm going to continue testing to see at what point it slows down to unusable if at all on the score I'm currently working on. Marc seems determined to fix the issues with continuous view so any testing will help. You can open new threads in the technology preview forum to discus any issues if you decide to help with testing.

Reply

• May 16, 2019 - 06:16

HI mike320, thanks for your response. By 'edit mode' I just meant any edit functions, like changing pitch, duration, inserting or adding notes, or clicking anything in the score. Sorry for the vagueness. By display mode, I meant single-page, continuous, etc.

But good news: the nightly build is working normally. I have no idea why the install versions have stopped working for me...could be a setting hiding somewhere or a windows thing. I even tried deleting the appdata. But I'm grateful for that portable nightly build!

Reply

• May 16, 2019 - 14:30

If there is a specific problem with the version that hasn't even been merged yet, it needs to be addressed in a thread outside of the original thread. The answer to the original problem is, it's being worked on. If you want to help test the fix please do. If there is a problem with that, it's not a released version so discussions of that should go into the Development and Technology preview forum to avoid people thinking the discussion of it's bugs might be related to a release version.

This all seems to be moot at this point, since Aaron has continued the discussion in the thread. He seems a little confused and it's just as well to keep the discussion here.

Reply

• May 16, 2019 - 06:10

Let's start with the most basic point here - entering a tuplet into a new score. is it only tuplets? Like, just usign the default empty score, press "N 5 C". Is it anything but instant? But "N 5 Ctrl+3 C" is slow?

Sounds overall like you have some sort of driver or library conflict going on.

Reply

• May 16, 2019 - 05:25

Hi Marc,

Just tested the 'unstable MS3.1 on Windows Platform',

So sorry to report that 'continuous view' still very very lagging while move notes up/down by mouse or keyboard. The sheet contains 6 staffs, around 270 bars.

Could it work as smooth as Page View or Single Page View......

Mainly, I edit many classical pieces with MS3 initially, add articulations which control by MIDI,
then final process at DAW.

So "Continuous View" is very very important.

Thank you for your great contributions again.

Reply

• May 16, 2019 - 06:16

The nature of continuous view is that it can't take full advantage of the speed improvements in page view. The main improvement in page view is only updating the system(s) that have changed on each edit, but of course, in continuous view, it's all one system. So what my change does is at least try to limit how uch updating we do for measures that have not changed. It's still going to be slower than page view, but it should be many time faster than 3.0.5 or 31 beta. Did you try some direct comaprisons? One way I like to tet is go to note input mode, select sixteenth duration, then press a letter/note key some fixed number of times - say, 20 - as fast as I can (under a second). Then use a stopwatch to time how long it takes all 20 notes to be entered. If I compare my build to the 3.1 beta, depending on the score, I'm seeing improvements of anywhere from twice as fast to literally 10 times as fast. Can you try a similar test, and report the timing for 3.0.5, 31 beta, and my build? Also can you attach one such score for me to test with myself?

Reply

• May 16, 2019 - 07:01

BTW, I just did another test with another large score (a concert band arrangement of Rite of Spring), and in a few trials of entering 32 sixteenths, got an average of around 80 seconds using 3.0.5, but under 10 seconds using my build. 2.3.2 was actually quite a bit worse - 20-30 seconds.

Just for grins, I tried taking advantage of the new command to turn off automatic placement (which 2.3.2 didn't have anyhow). This brought it down to a point where it was so fast it practically kept up with me as I pressed "C" as fast as I could, only a couple of seconds behind after entering 32 notes.

So I'm struggling to imagine how you could not be seeing improvement like this. You are sure you are using my build?

Reply

• May 16, 2019 - 11:21

I'd compared with MS3.05 and Unstable-MS3.1 again.

MS3.1, continuous view, Notes drag up/down by mouse, There are great improvement indeed,
but by keyboard, too little difference.

Hopefully, the coming builds fix lagging issue.

Moreover, is it related to this:-
Preference -> Canvas -> Draw antialiased

Suggestion: add an option 'Draft Mode'
Speedy note-input / edit mode, draft mode is acceptable.

Thank you again.

Reply

• May 16, 2019 - 15:33

Just to be clear, though: the changes is not in current 3.1 builds. It's only in the special AppVeyor build I posted the link to. Are you positive that is what you are testing? Again, when I test, the improvement is literally around a factor of 10, it should be impossible not to notice. Can you attach a score so I can test further?

Reply

• May 16, 2019 - 05:26

EDIT: The nightly build is working fine. I'm thinking maybe there is a setting somewhere or file in the windows system that is screwing with the fully installed versions. But thanks for the nightly build. You've just saved me!!

Btw, I'm not sure if uploading a demo score is helpful. I get the same results with every operation and every file -- large or small, new or old, native or import. Musescore 2 is snappy and fast. It feels good. Musescore 3 is worse than slow. It's literally unusable. I'm still happy to upload a few scores that I've been working on, just in case. In fact, I will...

Note: the "May the Fourth..." xml has export errors. I just figured out that musescore has a bug when exporting septuplets. I imagine I'm not the first to find this? Anyway, it plays and edits great on musescore 2. It's super laggy on musescore 3.

Note: the speed tests were really revealing. It took me over 5 minutes to create that in musescore 3 with keyboard and mouse. It took slightly more than one minute in musescore 2. From new score wizard to final save.

Attachment Size
May the Fourth 03_1 Aaron (musicxml ms3).musicxml 1.16 MB
Musescore2_Speed_Test.mscz 11.23 KB
Musescore3_Simple_Speed_Test.mscz 11.41 KB

Reply

• May 16, 2019 - 14:36

Look for the final release announcement for 3.1 when it comes along, hopefully in a week or two. It will mention the improved speed in continuous view if this has been included (which seems like a no brainer at this point). You will then be able to seamlessly continue working on your scores in an installed version with all of it's benefits.

Reply

• May 16, 2019 - 20:14

Just a curious...

Why Musescore, an open and free software, is available to the "most bad", and full commercial, Operating System? ???

Isn't it to work to the enemy? ???

BTW: I don't want to start a fighting. I just say that most of people thinks.

I don't have the problems this forum item describes because I work in Linux. SO... I just wonder... Why Musescore is running in another systems, knowing there should be issues (not presents in Linux)? ???

Maybe the time the development team is wasting to fix the inherent problems related with other OS, should be "invested" in Linux, ONLY...

Just an idea.

Reply

• May 16, 2019 - 21:01

First, the issues being discussed here are absolutely not OS-specific. Continuous view has the same performance problems on all systems, and all systems can potentially present driver, library, or other resource conflicts. In fact, hardly any issues of MuseScore are OS-specific, because almost all of the code is shared.

More importantly, though, MuseScore would not be anywhere near the success it is today if it were only used by a few thousand Linux users rather than millions of Windows & macOS users. There would be far fewer developers volunteering to help develop if it were only for Linux, far fewer users reporting bugs and helping each other out on forums, and far fewer scores being shared on musescore.com, etc.

There are no enemies here.

Reply

• May 16, 2019 - 22:44

Hi Jotape,
You're right, developing MuseScore for Windows only would allow to use native user interface and would make the software more intuitive and user friendly. But specially for you and the 3 other users of linux in the world, MuseScore is os independent (with the help of Qt).
As explained by Marc all that has nothing to do with the speed of the layout algorithm though.
p.s. to read with a pinch of salt (and yes I know there are Mac users)

Reply

• Jun 3, 2019 - 13:00

Thanks for the link. I have been using MuseScore 3 and indeed it seems very slow (on a score I imported from MuseScore 2). This alpha considerable speeds up editing in continuous mode.

I haven't tried MuseScore 3 and the alpha version on the same machine though, maybe I will give that a try to see if the problem is really solved by this build.

So far at least, editing speeds (on a ~15 instrument score of about 120 bars) are very much acceptable again :)

Reply

• Jun 3, 2019 - 13:37

Ah, yes! I meant that one :)

MuseScore updater was only reporting that 3.0.5 was available, so I was not aware this was already released. Good to know that it has the fix - so of course I will try this asap

Edit: downloaded the 3.1 (Linux) and it runs very smooth :D

Reply

• May 14, 2019 - 04:43

The problem is not related to soundfonts. It has to do with extraneous calculations that have nothing to do with what is being displayed in continuous view. There is actually an improvement to this being tested and a few bugs being worked out. Hopefully it will be able to be included in version 3.1 when it's released.

Reply

• May 14, 2019 - 05:03

Ah, that makes sense. I just imported the same MusicXML score in 3.0.5, 3.1 Beta, and 2.3.2. It plays smoothly and gracefully in 2.3.2 but lags severely in the others. I just don't understand, because Musescore 3 was running just fine a few weeks ago. I can't remember what changed or when. Maybe it was before I updated to 3.0.5. So frustrating.

Anyway, thanks for the link. I'll check it out.

Reply

• May 14, 2019 - 05:27

Continuous view playback has suffered several bugs like you describe. I haven't used it enough in version 3 to keep up with the playback issues, but I look forward to being able to use it again in the future. The slowdown that is supposed to be fixed is related to entering scores. It quickly gets to the point where the lag is unbearable when you edit something to the time it is displayed. This is the fix I pointed you to. I've heard nothing concerning playback improvements with this fix, so it might be interesting to find out if playback improves.

Reply

• Jul 20, 2019 - 14:24

The issue with MDL is specifically about startup time - the soundfonts in particular just take a long time to load. It should work normally once it has started. To eliminate the slow startup of MDL, you can go to View / Synthesizer and delete the soundfonts (the be sure to save that as the default). You won't have playback of the MDL instruments but you can still use the notation features.

Reply

• Aug 1, 2020 - 18:24

I can confirm that this is an issue for me too, even if it's not as bad as it is for you.

Just entering notes is no problem, but when I want to select a section with the mouse by holding shift it is really a nightmare. It lags a lot. I often use arrow keys instead just because of this. However, as other have commented, this is only an issue in "continuous view" when the score have lots of different parts.

I'm using Musescore 3.2.3+dfsg1-5 on Debian Linux.

Reply

• Aug 2, 2020 - 01:08

MuseScore should always be very fast with small / medium sized score. Older versions of MuseScore would get much slower with large scores (hundreds of measures, dozens of parts), but in general MuseScore 3 should be pretty fast with these too, most of the time. The few things that would be expected to be slow with very large scores are operations that require a full relayout of the entire score. Merely selecting something should never do that, but it's certainly possible some particular case gt missed in these optimizations. If you attach your score and precise steps to reproduce the problem, we can investigate further.

Reply

• Aug 2, 2020 - 17:56

3.2.3 is pretty old at this point, I'd recommend getting the latest AppImage. But, the performance improvements we put in place should be there. Anyhow, for me, using 3.5 release candidate AppImage on Debian buster, shift+drag is instant in continuous view with your score. That's with a decidedly not-powerful computer - a Chromebook, actually, using a bottom-end "M"-series low-power processor.

Is the lag you see similar to the lag if you do Ctrl+A to select all then do something like Ctrl+Up? That definitely triggers a full relayout, and it lags slightly for me, maybe as much as half a second. But the Shift+drag is, again, instant. If you are seeing a similar lag in both operations, it could indicate that Shift+drag wasn't as well optimized in 3.2.3 as in current releases - there definitely were some tweaks to that mouse interactions in general since then. So maybe 3.2.3 did do a full relayout on this operation whereas 3.5 does not.

Also, do other operations that don't actually affect the full score seem to lag, or it just this one? If it really is just a handful of mouse interactions, that would also be evidence for my theory.

BTWk to select a range of notes or measures I would never recommend Shift+drag. Easiest is usually click beginning, Shift+click end. Sometimes Shift plus cursor or tab can be faster also.

Reply

• Aug 2, 2020 - 19:01

Fair enough.

I'm using 3.2.3 because that's what's included in Debian Testing at the moment.

But I can confirm that those performance issues I mentioned are gone with version 3.5. I just tried the app image on the same score.

When I tried the C-a, C-up I got about one second delay. That goes for both 3.2.3 and 3.5. However, this is not something that is an issue for me. The mouse selection is. And as far as I can remember, that thing is the only performance thing that have been an issue for me at all, so about the rest I don't know. Using C-up on just a few notes works good on 3.2.3 and I have no issues there.

I thank you for your tip on a better way to select an area, and since my issue does not seem to be present in 3.5, this is a closed matter for me now. I only hope the package maintainers upgrade it to 3.5, because I don't like using app images unless I have to.

Reply

• Aug 2, 2020 - 19:11

FYI, while it's convenient in some ways that distribution maintainers attempt to build and supply their own versions of programs like MuseScore, the reality is, they often get details wrong, leading to all sorts of difficult-to-debug problems that turn out to be due to errors in how the distribution maintainers built the package. It's understandable, as they can't be experts on every single package out there. But, for this reason, we don't recommend using those third party builds. That's why we always provide the most recent version as an AppImage. These are always up to date and can be supported by us because we know we built it correctly. So even if you generally prefer using distribution-provided builds of other applications, I would highly encourage you not to rely on them for MuseScore.

Anyhow, the reason I asked about the Ctrl+Up was just to try to understand where the issue might have been coming from. From what you are saying, it does sound like my theory is correct that 3.2.3 was for whatever triggering a full layout on drag-select whereas 3.5 does not. But for the record, it's not just Ctrl+up, it's any operation on the full score, that will continue to take that extra second or whatever. That's true in both page and continuous view. We just try to make sure that only operations that need do do a full layout actually do, the rest only layout the part that has changed. That's how we manage to get most things responding quickly. Every once in a while some operation fall through the cracks and we discover it is triggering a full layout unnecessarily, and where possible we fix these. So keeping current is always going to be a good idea for performance.

Reply

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