Staff text in 1.3 score attaches to wrong note

• Jun 9, 2014 - 18:25
Type
Functional
Severity
S4 - Minor
Status
closed
Project

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?

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.