Wrong Accidental with key change after clef change
Reported version
3.5
Type
Graphical (UI)
Frequency
Few
Severity
S4 - Minor
Reproducibility
Randomly
Status
needs info
Regression
No
Workaround
Yes
Project
Actually the attached pictures shows it all:
When changing the clef in the middle of a line and then changing the key in the same line the accidentals of the new key signatures are on the same height as the old key. What's even more frustrating is that they will stay on the wrong heights for the next lines.
| Attachment | Size |
|---|---|
| Screenshot 2020-11-20 220053.png | 195.64 KB |
Comments
I can believe this happen for some specific order of operations, but when I tried it just now, it worked fine. So it's probably a very specific sequence that triggers this. In order to investigate, then, we need precise step by step instruments to follow. Could also be something unique to that score, so it would help to attach it as well.
Thanks for the fast response! Yeah i attach the score.
Step by step:
-Entering all the notes with Midi-Keyboard and Numpad
-Changing (all with drag and drop from palette) 1. The Bar line 2. the clef 3. the key signature
Strange enough, after closing and reopening MuseScore i can't reproduce the problem even on this file...
Not strange, I kind of expected that. When bugs like this happen - and they do happen - it's typically because we maintain an internal table of where the clef changes are, so we don't have to actually hunt through the score looking for them. If that internal table gets out of sync with reality - maybe some sequence of adding, deleting, undoing, redoing, adding/deleting measure, etc - then things are screwy until the table gets rebuilt. Which happens when you reload the file.
I have been able to reproduce it accidentally while editing some scores. As mentioned, there is a very easy workaround: reloading MuseScore seems to fix it entirely. However, I haven't been able to find a reliable reproduction method