Unterminated slurs multiply with every save

• Oct 25, 2016 - 18:19
P2 - Medium
S3 - Major

When a slur occurs that has no type="stop" entry in the mscx file, it not only does not display, but multiplies geometrically until the score file spans megabytes and is no longer usable.

See:https://musescore.org/en/node/138061 for details and sample files.

A possibly related issue may be similar treatment of hairpins, see: https://musescore.org/en/node/138691#comment-588421

The common denominator appears to be XML import, so that's probably the place to put some sanity checks in MS.


Maybe 2dada2a fixes this?

OK, I tried it, opening the huge score from https://musescore.org/en/node/138061#comment-587061 in this 2dada2a (took ages to load) and just saving it (took quite long), brought it down from 716k to 240k. Deleting the 'parts with the empty names and asaving again (took quite long again) brought it down to some very reasonable 72k and pretty close to the size from https://musescore.org/en/node/138061#comment-587686.

Openig the file in 2.0.3, ingnoring the warning that it had been created with a newer version and saving it again results in the attached presumably clean file of 64k.

So this commit apperently does fix the issue in that it cleans up the file, but I'm not sure it fixes the root cause of creating (or rather leaving) these orphaned slurs in the first place. Although with that fix, they at least won't accumulate over several saves

Attachment Size
2_Intermezzo_1.mscz 64.06 KB

I'm wondering if this is a "fix" in the wrong place.

If the only way that an unterminated slur can occur is via import from XML, then it makes little sense to incorporate this in the general case. Better to have the XML import code do some sanity checking and leave the main body of code untouched.

We have the seemingly parallel case of multiplying hairpins as well, which this fix would probably not affect. Again, I have to ask what produces the initial conditions for prolific hairpins. If it's once again, a badly-formed XML file, the answer should again be obvious.

Or so it seems to me.


The question is whether XML Import really is the culprit, or the frequent add/delete parts? Or something entirly different.
To find out we'd need steps to reproduce the issue

OK, I've imported it into 2.0.3 and saved it, 64k. Modified very slightly, ssaved again, stil 64k, repeated several times, still 64k.
Then I generatd pargs and saved, it bake larger (I fort the exact size, more than double)), removed parts, 68k, 4 more than before. genaretad parts again, 150k, removed them, back to 68 k again. Tried a few more times, up to 160k, down to 68k, up to 160k, down to 68 and so on and so forth.
So this isn't it either, it it is growing, then pretty slow, some 100 Bytes or so maybe.
I noticed though that MuseScore became slower and apparently made one (of 8) cores busy, total load of ~13%

Status active fixed
Reported version 2.1  

Saving such a file in MuseScore 3(.6.2) seems to get rid of all these superfluous slurs