Wrong Accidental with key change after clef change

• Nov 20, 2020 - 21:06
Reported version
3.5
Type
Graphical (UI)
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
needs info
Regression
No
Workaround
No
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

Status active needs info

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

Attachment Size
Trio.mscz 30.81 KB

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.