MS 2.03 Dragging text is extremely slow on some scores

• Oct 19, 2016 - 20:04

I'm using MuseScore 2.03 on x64 Ubuntu. System has 8GB memory with quad-core AMD CPU.

I'm working a quintet piece in four movements. The first, longest movement (about 210 measures) worked flawlessly for me, allowing quick changes to both text and graphic content (e.g. hairpins).

The second movement is roughly half the length and about the same complexity, but dragging text (e.g. dynamics, tempo markings) is painfully slow, lagging the mouse by 10-15 seconds or more. Moving graphical items (accents, hairpins, etc.) isn't nearly as slow.

Navigator is off, sluggishness is unchanged in both page and continuous view.

Getting this movement print-ready is very frustrating. I've attached the movement. Perhaps someone can figure out what's happening.

I'd be grateful.

Thanks,
Chuck

Attachment Size
2_Intermezzo.mscz 172.56 KB

Comments

• Oct 19, 2016 - 20:15

Unfortunately, here, on Vista, I can not find the problem you say.
Try to resize the Navigator.
I made a small change (line break) checks whether something has changed with the saved file with Windows.
__ Edit __
can you assign to MuseScore better 'priorities' in running processes?

Attachment Size
2_IntermezzoBis.mscz 176.02 KB

Reply

• Oct 19, 2016 - 20:46

Thanks for trying it out on Windows, but your score behaves the same--very, very sluggish to drag text in either page or continuous view.

Navigator is off, so resizing that won't help. MS is the only user task running--as I mentioned, a longer score works fine.

I wonder if this is an Ubuntu- or Linux-related problem. I can try MS 2.0.3 on a different distro.

Reply

• Oct 19, 2016 - 23:19

I can't reproduce either, and my computer is less powerful than yours. It's a fairly big score so things are slightly sluggish, but not abnormally so, and text is no different from other elements - lag measured in milleseconds, not seconds. Is there a *specific* text element we should try? How about moving with the cursor keys or with the Inspector?

Could be the font you are using is not well optimized for Ubuntu in some way. I'm using Windows 10 and the font shows as Times New Roman for most elements. Maybe you'd have better luck sticking with the default FreeSerif font?

Reply

• Oct 20, 2016 - 00:08

I deleted all parts and then re-created them with a "new all" parts action. Now they behave as they should.

So. this is solved for the time being, but I suspect there's something really strange in the way parts are being handled that causes this. From now on, I'll create the score without parts and then create parts only when I'm satisfied with the score--and not to depend on the "link back to the score changes to a part" feature.

Thanks all.

Chuck

Reply

• Oct 20, 2016 - 21:06

For performance reasons it's just as well to wait until towards the end to generate parts - everything will be twice as slow if there are parts. But still, normally we're talking about a few more fractions of a second, not many more seconds. Whatever you were seeing appears to be an extremely rare fluke - actually, I've never heard anyone report anything like this before. I wouldn't assume it's something you'll see often if at all again.

Reply

• Oct 20, 2016 - 23:48

Thanks, let's hope so. Clearly, it's necessary to edit parts at some time during the production process. Things are never guaranteed to be in the right place when parts are auto-extracted.

Is there any way to "decouple" the parts from the score (and each other), such that changes are *not* propagated to other parts? This is the way I'd work when using Sibelius--do the whole thing, extract parts, edit parts. Never a problem even on a comparatively slow Pentium 1 back in the Sibelius 2 days.

I'm tempted to see what happens when I try to edit some of my full orchestra parts. I mean the issues I'm having are with a simple quintet, not a 25-staff system that runs for 300 measures.

--Chuck

Reply

• Oct 23, 2016 - 05:50

There's something very, very wrong with MuseScore 2.0.3.

After exporting the scores for individual parts, I deleted them from the full score. Everything seemed to be better.

But after a couple of edits to the score, the size has ballooned from 141K to 712K, it takes a half-hour to load under either Ubuntu or Windows XP and the result is essentially unusable. Every time I make an edit or two, the score adds a couple of hundred K.

How can I get my score back to a reasonable size again? This is just unworkable.

Let me know what I can do to help diagnose this. I need a working MuseScore before I start on the next (longer) movement.

Thanks for the help,
Chuck

Attachment Size
2_Intermezzo.mscz 712.51 KB

Reply

• Oct 23, 2016 - 07:41

Something went very wrong with the linked parts of this score, none of them has a name?!?

Looking inside the file I see huge sections of it dealing with slurs, several 100000 lines

Opening it with a self built development version gives tons os warnings reg. an unknown XML tag "up", related to slurs too (apperently their direction), also tons of messages about broken slurs

Reply

• Oct 23, 2016 - 18:04

Edits between the first (140K) and the last (720K) versions of the score were mostly pretty minor--removal of repeats, adding/removing text, re-spelling of accidentals, etc.

As I noted in the first message, working with linked parts was getting very slow, so I extracted parts, then deleted them and continued to work on the score until it was time for another "cut", then did a "new all" for parts, extracted them again, followed by a delete of all parts, and so on.

Using Windows or Linux makes absolutely no difference to the end result.

I'm sure you're aware that getting score and parts ready is a many-times-through iterative process. The problem is that with each edit, the file grows like Topsy.

Right now, I'd like to know how I can get my full score back in usable form--and what I can do to avoid these problems on succeeding movements.

I like MuseScore very much and am getting used to it, so I'm willing to help out in any way I can.

Thanks,
Chuck

Reply

• Oct 23, 2016 - 19:38

I think that's the issue--parts being created/deleted repeatedly. It would seem that deleting a part doesn't really delete it, but rather simply unlinks it. That may also account for the slowdown in the editing as well--changes are still being propagated to the now-invisible parts.

FWIW, I do routinely modify (extend/retract) existing slurs as part of my edits (select the slur, shift-left or shift-right to modify). But as far as I know, I have no "hanging" slurs or ties. I'm pretty careful about that. Playback at least verifies that I have no hanging ties.

But the multiple "New all" parts for editing, followed by their deletion before a save probably is accounting for the growth of the file.

How do I delete the large number of unnamed/unlinked parts? Will exporting the score perform that function?

--Chuck

Reply

• Oct 23, 2016 - 20:50

Here's something interesting--

I attempted to export the score as an uncompressed MuseScore file (mscx). After several megabytes of output, I killed the MuseScore process. The output told an interesting story.

Everything looking fine until the following occurred:

(see attached file--text doesn't come through)

Clearly, there's something going on in this measure. How do I go about locating it in the source? Perhaps I can simply delete it.

--Chuck

Attachment Size
x.txt 827 bytes

Reply

• Oct 24, 2016 - 04:51

I wrote some code to clean up the excess slurs in the score.

I removed the tags for slurs 78-16461, 16638-33021, 33549-49932, 49936-49951, 50111-66494.

That's a lot of slurs! (a few thousand?) And I'm not absolutely certain that I got them all.

At any rate, the cleaned-up score is attached.
-----------------------
That being said, I think I know what created the superfluous slurs.

Consider a measure with a quarter (crochet) tied to an eighth (quaver), as part of a slur. Now suppose you want to change the pair to a single dotted quarter. So you select the quarter and add a dot to it. It breaks the slur and slur disappears. So you re-add one.

I think that's what happened.

Also, the added parts appear to be unnamed, and so I deleted those. I don't know where they came from.

Input is most certainly welcome--I think I'm on the right track.

--Chuck

Attachment Size
2_Intermezzo-cleaned.mscz 67.25 KB

Reply

• Oct 24, 2016 - 21:15

It would seem that MuseScore lacks a simple sanity check. To wit, if I take the 712KB compressed file linked above, decompress it, and then look for slur start/stop, I get the following results (Linux CLI):


$ grep "Slur type=\"stop\"" *.mscx | wc
622 1866 26028
$ grep "Slur type=\"start\"" *.mscx | wc
66284 198852 2839238

Or, roughly 65K more slur "starts" than "stops". The follow-on, of course, is that the bytes really accumulate with all of the codes that reference the un-stopped slurs.

I'm going to throw together a little tool for myself that will parse a .mscx file in two passes and delete any references to slurs that start but do not stop. Hopefully, this will solve the problem in the near future, but MS really should have such a check (or at least a plugin) to deal with this. I haven't researched MS plugins to determine if this can be done via a plugin.

ETA: Done and the tool works just fine. Probably about a 100 lines of C. If anyone needs this thing, just drop me a line. No more rogue slurs.

--Chuck

Reply

• Oct 25, 2016 - 00:57

I have stumbled on a similar issue a year ago.

I have imported and an xml file (which was exported from Finale) and after a month I have noticed slowness when opening the file especially using the Android app. Then I noticed that the file size was much bigger than I would expect although this was partially masked by the fact that .mscz is stored with compression but the raw .mscx file had several MBytes. The increase in size was solely attributable to slurs that did not have the corresponding <slur type="stop" id="nn"> tag.

At that time I have edited the .mscx file in a text editor and removed the invalid slurs manually as they occurred in one or two spots only, so the slur invasion was easily contained.

I was not able to find the reason for the "orphaned" slurs. I tried recently with the same score but probably a different Finale version and (for sure) a different version of MuseScore (2.0.3) and I could not get any invalid slur in the imported file.

It is worthwhile to emphasize that every "orphaned" slur is invisible or hidden but gets doubled every time when the score is being saved, so at first you won't notice any slowness but after saving the file 16 times one of them multiplies expotentially to 65,536 and that's when you start noticing that something is wrong because MuseScore is too busy with handling those slurs.

I have also created an awk/gawk script (attached) which removes the "orphaned" slurs from the score.

Attachment Size
StopSlurs.awk_.txt 1.57 KB

Reply

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