2.0.3 Borderline Unusable - Incredibly slow and unresponsive, not Navigator

• Feb 19, 2017 - 18:16

Hello there.

I've used Musescore in the past, and it's worked pretty well for me before then. I got a new computer last year, and finally decided to get Musescore on this computer too, opting for the new version, of course. What I didn't realize, however, was how completely unusable the software would be.

I'm running Windows 10 with 8 GB RAM on a 2.5 GHz dual core processor, and this thing just does not work. When I looked on the forums however, I was shocked that this problem was happening ONLY with people using Navigator. I never used that a day in my life, and it's still horribly slow and unresponsive. When I want to place a note, the entire software locks up for several minutes before the note is placed. When I want to save, same deal, as with starting playback. It's HORRIBLE, especially considering this is supposedly the best free notation software out there, and NOBODY ELSE seems to have this problem.

If there's anybody out there who has any ideas on how this can be solved, please let me know. I looked all through the forums, and nobody has had this problem with 2.0.3.

Thank you for your time.

- Mike


Comments

I and several other people have reported this problem on Windows 10. This only happens to me when my score gets to about 150 measures. The extreme slow you are talking about sounds like the score is at around 400 or more measures.

When I have a score like that, I delete everything but about 10-20 empty measures and save as "My score work space" and then open both the score I was working on and my work space. It doesn't matter if you view them in split screen or alternate between the two, but the speed is much better in the work space. Every time I find a good stopping spot I cut and paste the measures to the actual score. One thing to keep in mind is that no system data is copied, this includes such things as rehearsal marks, tempo changes key and time signatures. Anything that affects every instrument. I patiently put those into my actual score before pasting the info from the work space.

I have 2 suspicions about this.
1. MS redraws every measure after each edit (even those you cannot see). This should be fixed in 3.0, but that will come several months after 2.1 which hasn't been released yet.
2. Sound fonts may be filling up your memory and causing windows to swap data between the computer and virtual memory on your hard drive. If you have several sound fonts loaded, then remove all the ones you are not using on that score and see if that helps. Possibly even remove any zerberus fonts if you have any of those loaded and see if that helps the speed. After the score is finished reload any fonts you want and save them to the score. It will cause a pause before playback, but it should help with the initial score entry.

One more thing that will help speed it up, turn off auto save. The programs locks up during auto save, so turn it off and remember to save often.

In reply to by mike320

I'll reply to this comment since it's the most recent one.

Firstly, I'm so glad that so many people have responded so quickly to this issue. The thing is, the project I'm working with is barely above 100 measures. It may be longer later, but so far it's not even at 150, never mind 400. One thing I wonder about is if the many, MANY time signature changes have anything to do with the slow down, but even then, it just seems ridiculous to me.

I have no soundfonts loaded, I disabled autosave and check for update, yet every time I load my project, it IMMEDIATELY locks up for several minutes. While I could understand if the massive amount of time signature changes was the issue, 1. I've never had that happen in any other program I've used that dealt with similar things, 2. I can't really change that for the way the song is.

There also is a program using a lot of CPU and memory...MuseScore. There are times when it's entirely idle and yet still taking up about 15-20% of my CPU, and that's when it locks up. Once the usage drops during, say, playback, it works like a charm.

Again, thank you all for your input, and I hope this can get solved soon.

In reply to by Michael Mackay

Definitely seems likely to be something unique to your particular score - some corruption within it, perhaps. Time signature changes don't in themselves cause problems, but it's possible the numerous changes somehow triggered a bug specific to something you did in this particular score.

Test with other scores to see if this the slowdown seems localized to this one, and if so, please attach the score you are having trouble with. Could be interesting to first try removing half the measures and see if the problem persists, then maybe try again removing the other half, etc.

In reply to by Marc Sabatella

Well, I downloaded the most recent nightly version of MuseScore (let's get the name right, Mac), and it also locked up on that. So I can be confident that at the very least, my computer does not like that project. Then again, it is subject to being unstable, so maybe that wasn't the best test.

All the demo files work like dreams. It may be a combination of the many instruments/staves and many time signature changes. If that's the case, I may need to find a different program or method for notation. I'm only doing it this way as I plan on giving sheet music to people playing different instruments like organ (which I forgot to add), strings, etc.

I'll attach the file so other people can see it. It's just called No Name because I don't know what to name it yet. It's GOING to be prog metal, but I'll also need to see if I can add more instruments, as I forgot a few initially.

Once not locked up (on any version of MuseScore), entering notes doesn't take that long, unless layering two notes at the same time, something I tried to do with the vocals before I realized I could spare myself much pain by using voices. The guitar is also using piano pedal notation because I cannot for the life of me figure out how to notate "let ring" without using messy ties or awkward voice changes. So if anyone knows how I should do that, I'd love to know that as well.

Hope this helps!

Attachment Size
No_Name.mscz 1.49 MB

In reply to by Michael Mackay

Yes, there is definitely a bad corruption within this score - thousands upon thousands of spurious pedal markings. A tip-off is the file size, which is much bigger than a score of this scope has any business being. Opening the MSCZ archive and looking at the MSCX file within it using a text editor shows the problem right away.

See #138756: Unterminated slurs multiply with every save for more information on this bug. There are partial solutions given there, including a code change that has been merged for 3.0 but apparently not for 2.1 - something we should consider. In that case, the file in question came from MusicXML import - was this the case for you as well?

In reply to by Marc Sabatella

I actually found this on my own trying to delete the pedals just before you posted. This was not the case. I created a new composition from scratch, though did some copy and paste things. I'm not sure what really happened here, as there was definitely termination on all slurs and pedals. But I'm glad we at least have a source. Only problem is that I might have to delete every single one of those measures and do them again, else waste several hours deleting thousands upon thousands of pedal markings.

In reply to by Michael Mackay

It's easy to delete all pedal markings at once: right click one, Select / All Similar Elements, hit Delete. I don't know that this will actually fix the underlying problems in your score; the spurious tags they may well re-appear on next save. Worth a shot.

As for how to notate "let ring", it depends on why you are wanting to notate it. Not sure how familiar you are with guitar, but letting ring is the natural state of affairs for guitar so you ordinarily don't do anything to notate it. Only in special cases where it might be seen as somehow unexpected given the context.

In reply to by Marc Sabatella

Deleting the pedal markers improved the workflow stupendously. Guitar is actually my main instrument, however I usually work with tablature, and even when I use sheet music (when it's more available than tabs, usually), it doesn't generally have any broken chords and the like, so I never saw how it was notated. I also tried to add it in an attempt to make it play back more similarly to how it will sound when it comes time to record.

Thank you all for your help. Now I at least know that this software is not, in fact, garbage.

In reply to by Michael Mackay

See: 8No_Name.mscz
or with the top standard staff in Bass clef as initially (no sure why you do that for a guitar): 7No_Name.mscz (but it's not related to the problem)

For "let ring", just use simple/regular text ie write on the score: "let ring"!
Don't understand what was your goal to use pedal markings. To simulate the "let ring" I presume?
Not a good idea, and probably one or the main problem (time signatures in my opinion are not involved)
BTW, these pedal markings are duplicate in the linked tab staff. So, additionnal problem.
And you said using copy-paste.
Could you provide more detail on the used process? (when, how many etc.)

In reply to by cadiz1

The copy and pasting was simply taking parts from earlier in the song, copying them, and pasting them. This seems to have been what caused the pedal problems in the first place. And yes, I was using it to simulate the sound, as I figured "if it's proper notation, it will sound like what I want." Evidently not.

The issue has been solved, it was due to several thousand pedal markings layered atop one another (multiplied twenty-fold) causing an outrageous file size and causing MuseScore to overload. I felt the need to notate it as later sections will not utilize it.

The bass clef was utilized as the guitar is in Drop C, and the treble clef 8vb seemed a bit cumbersome to use with such low notes (E2 on a treble clef isn't exactly elegant, either).

In reply to by Michael Mackay

Part of the problem with the spurious pedal markings has to do with resizing them by double clicking them and changing the way they look by dragging rather than using shift-arrow to move the end of the line (which is what a pedal mark is) or hairpin (a [de]crescendo).

Unfortunately no one has been able to reproduce this effect exactly so someone can run it through the debugger and find the offending code :(

In reply to by mike320

I actually made sure to use shift-arrow every single time. There was only one time that I slipped up, and I quickly undid the action. I'm not sure what caused the glitch to happen, but at the very least I won't have to worry about it now that I'm not using pedals...unless I add piano parts.

In reply to by Michael Mackay

The problem is definitely specific to this piece.
I work with MS every day.
And each file I work with is extremely smooth. Until I meet with this special piece :)
I have never encountered anything problematic until this piece.

Result: Not open in 5 min. Runtime memory: 285M and growing up.
Action: Force to close.
-----
Win 7, 3 GB Ram. It was tested with MS 2.03 and MS Nightly 2.1.

It took several minutes for my computer to load the corrupt score and several more to select all the pedal lines so I could delete them and see what's going on. I'm still waiting on that by the way.

In the mean time, I thought it was weird that you used the bass clef on the guitar rather than the same clef as on the tenor part. If you didn't see it, it's in the advanced palettes, not the basic. Since you started with the tab and added the standard staff later, MS defaulted to a bass clef for the linked staff. This isn't really a bug, but MS could be smarter about the clefs it assigns staffs (like looking at the lowest playable note and not used the bass clef if it isn't below the F at the bottom.

BTW, still waiting....

In reply to by mike320

The issue was multiple pedal markings lain on top of each other. I'm suspecting that something happened as a result of me copying and pasting parts from earlier in the song, as it only happens part way through. Now it works fine. As for the bass clef, the lowest note on the guitar used is a C2, which is significantly lower than standard bass voice and also the same note as the low note on a cello. Therefore, I thought it necessary to use a bass clef rather than treble 8vb. It still extends a bit low (and high), but it's a bit tidier.

In reply to by Michael Mackay

The treble 8vb is the standard clef for the electric guitar. I thought you might not know abut that clef in MuseScore. Must guitars go down to E2 (which would be bass clef in my example), but MS puts a second unlinked staff for a violin in bass clef also, but alto for the viola - which has no logic.

BTW, I'm still waiting for MS to select all the pedal marks.

In reply to by mike320

Yeah, it took like fifteen minutes for me, and that was just deleting the bars outright and starting over again. It was literally thousands upon thousands of the damn things atop one another, times the amount of lines that look thicker (which I'll assume is about twenty). So that's at LEAST twenty thousand pedal markers to select. Not sure what the hell happened to do THAT.

In reply to by mike320

While I believe you are correct that no one actually knows the root cause of these "broken" slurs, it should indeed be fixed in 3.0 because there is code specifically to prevent these "broken" slurs from ever being written to the file.

The reason there is so many is that I believe the number doubles at each save. That might even include the auto-saves that happen every two minutes, although I'm not sure about that.

I think some sort of corruption occurred in the file as the uncompressed file is 45Mb and contains over 160000 pedal marks (way more than you'd usually copy and paste, I suspect).

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