Bug Report: Score formatted incorrectly, when viewed with the mobile Android Musescore app
This Score
is formatted incorrect, when viewed with the Android Musescore App (latest version).
Not only visually, but also in terms of playing the score.
The Playback feature first played the Bass notes and then the treble clef notes, and not both simultaneously.
I hope this helps, fixing the bug. For now, this error only occurred with this score.
Comments
Seems https isn't working inside those double square bracktets, if it is right at the start. So just adding a single word in front, fixes it...
This Score
The score looks quite messed up in 2.0 as well - not surprising since they use the same basic layout engine. Starting with measure 2, there are notes in the wrong order, clefs in the middle of measures, etc.
The problem appears to be the "tick" tags on the pedal symbols. They appear to have the incorrect values - a tick of "240" for the first pedal marking of measure 2, even though at that point we should be into the thousands, and so on.
I'm pretty sure this stems from the issues discussed in #26091: Staff text in 1.3 score attaches to wrong note. In particular, my comment at https://musescore.org/en/node/26091#comment-103326, where I say:
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.
I wouldn't be surprised if this isn't the very score in question - I know we did look at a lot of scores from this particular user as test cases.
I think this score probably counts as corrupt - those tick vaues are just bad - but we need some better way of dealing with scores like this. Maybe we could ignore tick tags on symbol elements if they are clearly in the wrong measure?
In reply to The score looks quite messed by Marc Sabatella
Filed bug report to issue tracker: #56146: Bad layout on load of 1.3 score with incorrect tick tag on symbol
It may be that this is just one anomalous corrupt score and there is nothing to be done, but perhaps we can find a solution to let this score load within breaking other scores as the previous fix for this score did.
BTW, you can get this score to load in 2.0 just fine by loading it in 1.3 and deleting the pedal markings. I've attached such a version here.
Probably if you have the paitence you could get fancy and delete just the markings in the measures where there is a problem, but it might be a bit of trial and error to figure that out. Measures 2-4 at least, it seems.
I found the right person to ping, and it appears this issue is now fixed in the latest nightly builds. Thanks, trig-ger!
Note that to the best of my current understanding, there were actually somewhat *different* problems with the MIDI file in this thread versus the one in the issue #53121: Midi import chooses accidentals poorly (for this file). Apparently both files had bad / incomplete key signature information, but the specific problems were different enough that the same fix did not apply to both. The current nightly now fixes both of these on import, I won't be surprised if there aren't other MIDI files out there will yet different problems in their key signature representation that still won't read correctly. The export/import workaround might be the best general solution if/when this happens in the future.