Crash when adjusting pitch of a particular note
100% repeatable with the attached score.
1) Open the score
2) Navigate to measure 50
3) Click on the first note on the second staff (it's a B) to select it
4) Hit down-arrow once to lower the B to Bb.
Result: Crash
An alternate repro is to click on the 2 digit on the tablature and try to adjust it there.
Note that only that note appears to cause the problem. Other notes in the measure are adjustable and other notes that have a chord symbol attached are adjustable.
Removing the chord symbol/Harmony element does not prevent the crash.
Changing the note by typing a letter does not, however, cause the crash and once the note has been changed the crash does not appear to recur, even if set back to a B. The second attachment ("nocrashon50") is the result of using this method to modify the score, set the note back to B, and then save. From a quick look at the diff, it looks like the only difference in these two scores is that some (or all) of the doubled notes (i.e., same note played on two strings) are reversed in position in the XML. None of these occur in measure 50.
Repros with 2.0.2 and MuseScoreNightly-2015-12-02-1810-77e980d on Windows 10.
This score is not infected with the linkedTo issue I previously reported (and it does not have a Part for the linked staves).
| Attachment | Size |
|---|---|
| Double_Chocolate_Duet-crashon50.mscx | 633.01 KB |
| Double_Chocolate_Duet-nocrashon50.mscx | 633.01 KB |
Comments
After changing and re-saving the score, the reversed doubled notes were reversed back, resulting in an identical score to the one that I repro'd the crash on if lid changes are ignored. That is, the only differences between the crashing one and the non-crashing one are lid values (many or all of which are different between the two versions).
I'm attaching here the more similar version.
I think the score is corrupt somehow; there seems to a note linked to a a chord symbol. Any idea how this might have happened?
I had been adding chord symbols. I think on that note I had added a fretboard diagram, then chord symbol, then removed the fretboard diagram. Not sure of the exact sequence, though.
If you figure out how to reproduce the sequence, let us know.
The interesting difference between the crashing and not crashing versions is at line 12088 of the crashing version, which assigns the Harmony for measure 2 an lid of 1841, which is the lid of the note B (pitch 71) in the first chord of measure 50. So indeed the Note and Harmony appear to be incorrectly linked.
In the fixed version, the Harmony for measure 2 no longer has any lid at all.
Since the ukulele part is not present in either of these versions, it makes sense for the harmony to not have a link id. The real question appears to be "How did the Harmony element get a link to nothing"? And unfortunately the answer is most likely lost in the history of this particular score and its suffering from the linkedTo issue with linked staffs in a Part (https://musescore.org/en/node/91351).
So 91351: Adding Chord Symbol causes overabundance of linkedTo and Harmony elements" is most likely a repro closer to the root cause.
I was again able to reproduce this state (lid of a Harmony element matches that of a note), but not in a clean repro. Again, it resulted in editing a score with a Part containing linked staves. Basically editing such a score is very problematic. As before, there were too many linkedTo elements and both FretDiagram and Harmony elements were getting duplicated. These are symptoms of 91351 and likely the root cause of this issue. I'm going to call this a dupe of that one.
On the other hand, this could be its own bug. It looks like LIDs on Harmony elements are ignored when there is no linked part (i.e., when the Part existed but has been deleted). The repro does appear to involve adding and removing Parts, but all the cases I've hit involved linked staves in the deleted Part so not sure what the interaction of the other bug is with this one. The other is definitely more critical.