Bad layout on load of 1.3 score with incorrect tick tag on symbol

• Apr 12, 2015 - 17:48
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Ubuntu 14.04, GIT commit: c73eb49

1) load attached score, created in 1.3

Result: it's badly corrupted in measures 2-4 - notes in the wrong order, clefs and key signatures in the middle of measures, etc.

Reported as an issue with Android app in https://musescore.org/en/node/55691. I *think* we have found the score that was reponsible for this comment:

https://musescore.org/en/node/55691

In fact, circumstantial evidence makes me pretty sure this is the one. If it's literally the only one with these bad symbol tags, we could say, corrupt 1.3 score, too bad. But if it's indicative of a problem that might exist in other scores, I guess we need a solution. It would be nice to be able to skip tick tags for symnbols if we can detect the symbol is attached to a chord or note, or if we can detect the tick is not within the current measure. But I'm not sure either of those bits of information is available - the symbol hasn't been added to the score yet and doesn't have a parent.


Comments

Looks like it is easy enough enough to create a bad score like this in 1.3. Just attach a symbol to a note, then copy that symbol and paste it to a note in another measure. You don't *always* get a tick tag written - seems to depend on what else is going on - but I did manage to reproduce it.

I tried a coupe of different potential fixes. Only one that works reliably enough to be worthwhile is to explicitly set the parent of symbols to "this" in Measure::read(), and then, in the section of code where we decide whether or not to honor tick tags, only doing so for symbols if the parent is valid and is of type MEASURE.

What I don't know is if there are any unforeseen side effects of setting parent too soon. I'll test some more, but so far so good.

Status (old) active patch (code needs review)

https://github.com/musescore/MuseScore/pull/1942

This definitely works for the problem score here and some other test cases I constructed. I only changed the behavior for 1.3 scores - 2.0 scores will be unaffected. I am pretty sure this is a good fix and won't break anything, but it is admittedly a bit of a hack, just to work around a bug in 1.3.