Unterminated slurs multiply with every save
Priority
P2 - Medium
Type
Functional
Severity
S3 - Major
Status
closed
Regression
No
Workaround
No
Project
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.
Comments
cross ref. to #138691: Musescore file is huge due to one measure
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
Guess we need that fix for the 2.0.4 branch too.
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.
--Chuck
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
Okay, here's the original XML for the "Intermezzo" imported from Finale 2008a.
I haven't re-run this through MuseScore yet.
--Chuck
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%
Can we pin down the measure numbers where the multiplying slurs occur? That might jog my memory as to what I did.
Came up again in https://musescore.org/en/node/147581
For a simple "C" program to remove the many slurs, see https://musescore.org/en/node/138061
The multiplication seems to be linked to deleting or modifying tuplets with slurs, as nearly as I can figure.
Saving such a file in MuseScore 3(.6.2) seems to get rid of all these superfluous slurs
Automatically closed -- issue fixed for 2 weeks with no activity.