Slurs loses connection to notes if keyboard used to change pitch of notes

• Jan 8, 2016 - 03:39
Type
Functional
Severity
S3 - Major
Status
closed
Project
MuseScore

1. Open attached score in released MuseScore 2.0.2 or any nightly build.
2. Click on either the C at the end of the measure or the G at the beginning, and move it up and down, either with the up/down arrow keys or by dragging with the mouse. Notice that the end of the slur moves to stay connected to the note. Move the note back to its original pitch, click on it, and enter note input mode.
4. If you clicked on the C, type [G]. If you clicked on the G, type [C].

Expected behavior: Same as if the pitch is changed by other means.
Problem behavior: Slur loses its connection and remains hanging, far away from the note.

I'm not sure exactly what this means is happening, but the fact that [Cmd]+[R] doesn't fix the layout suggests that it's not going to be easy to solve.

Attachment Size
Disconnected slur.mscz 5 KB

Comments

• Jan 8, 2016 - 05:56

FWIW, the word "re-pitch" in the title confused me a little - I tried actually using repitch mode, and it works fine. The problem only happens if you *don't* use repitch mode.

Reply

• Jan 8, 2016 - 14:00
Title Slurs loses connection to notes if notes re-pitched via keyboard ⇒ Slurs loses connection to notes if keyboard used to change pitch of notes

Sorry, I should have figured out a better way to concisely express it.

Reply

• Jan 13, 2016 - 18:47

The problem is that when the old chord is removed to make room for the new, nobody tells the slur this, so it is still trying to layout to the old chord - which is actually deleted at this point. Chances are pretty good you could get it to crash by continuing to mess with the score after that. Also, the shift in layout that happens on save / load is worrisome. This could relate to some reports of lines shifting on save / load, although I think most of those reports related to hairpins and I don't think this would likely affect those. You never know, though. Also, the same issue happens if you delete the chord (leaving a rest).

I have a fix, just find any slurs attached to the chord when removing it and reset the startElement and/or endElement. The trick is finding slurs attached to the chord being removed. I stole some code from the accessibility display that works, but I want to see if there is a more direct way.

Reply