Staff text in 1.3 score attaches to wrong note
Ubuntu Studio 14.04, GIT commit: ea51a17
1) open attached score (created in 1.3) using both MuseScore 1.3 and a development build
2) look at the staff text in measure 2
Result: 1.3 shows it as I created it - attached to the note on beat 2 (the text contains a bunch of embedded spaces, so it looks like 2 texts on beats 2 & 4, but it's actually just one on beat 2). 2.0 shows it on beat 1. Depending on the specific score (whether there are chord symbols?), it sometimes appears on beat 3.
Attachment | Size |
---|---|
staff-text-only.mscz | 1.48 KB |
Comments
The issue is this line:
https://github.com/musescore/MuseScore/blob/master/libmscore/element.cp…
Apparently due to various other problems, we are deliberately not honoring "tick" tags for certain items. I'd like to understand what all the issues actually are. The specific thread mentioned in the comment involves a score that contains an interaction between a symbol and staff text element. If you skip the "tick" tag for one, you have to skip it for both. But it isn't clear to me why we have to skip either. The score loads fine if I simply the above line to just "if (val >= 0)", but I guess other things must go wrong somewhere. Does anyone know what, and if we could find another way around it?
So far I've found:
http://musescore.org/en/node/25572
#25619: Rehearsal mark from MuseScore 1.3 causes bad layout and crash
#21981: Mid-bar tempo marking aligns at the start of bar
#21609: 1.3 score featuring time signature appearing before clef
#21612: tempo text in 1.3 can corrupt scores opened in 2.0
#21211: Score is corrupt if glissando had been pasted
and the following commit, for which I can't find a specific issue:
https://github.com/musescore/MuseScore/commit/a201385f13f0458df06e824f6…
Maybe by stepping back and looking at all of these together, we can find a way to fix them all without losing the position of staff texts.
Posting mostly for my own benefit so I don't forget what I've learned, but I'd love feedback if anyone cares to look at this with me.
I've gone through all of the above cases, as well as the thread referenced in the comment in the code:
http://musescore.org/en/node/25572
and the other score mentioned in that thread:
http://musescore.com/nicolas/scores/58389
The bottom line is that I can get all of the scores to load properly by eliminating the check for SYMBOL and STAFF_TEXT, instead checking for GLISSANDO and FINGERING only. The latter checks are necessary to work around bugs in 1.X where the elements could contain invalid tick information. Luckily the tick is not needed for those items since they are by definition attached to chords or notes already.
However, tick information *is* needed for SYMBOL and STAFF_TEXT or else these items will always render at the beginning of the measure even when attached to later beats. We really can't just ignore tick completely for these elements.
As far as I can tell, the only reason for not reading tick on STAFF_TEXT was to work around a bug that appears to have been *caused* by not reading it for SYMBOL. I am guessing the bug that caused tick to be skipped for SYMBOL was something like the ones for GLISSANDO and FINGERING - in some particular case, the tick was invalid. Symbols *can* be attached to chords or notes in 1,3 scores, in which case the tick would be irrelevant and could be safely ignored. Ideally, the code here would skip the read of tick if the element being read has a chord or note for a parent - but unfortunately, that information is not available at this time (parent has not been set).
I would still love to see the score that triggered the change to not read tick for SYMBOL elements. But I searched the issue tracked and forum pretty thoroughly (looking at all activity that occurred in late August 212) and came up empty.
So far, I can't reproduce a problem if I removed that check. I'm tempted to say, whatever score prompted that could just be written off as being corrupt; it's more important that "good" scores load correctly.
FWIW, here is a PR with the code I have, liberally commented:
https://github.com/musescore/MuseScore/pull/971
Fixed in c1aef0603a
Automatically closed -- issue fixed for 2 weeks with no activity.