insert measure in front of key sig creates measure with wrong key sig; clefs too

• Aug 16, 2014 - 18:20
S3 - Major

1. Create score in c major.
2. Insert c minor key sig in measure 2.
3. Select measure 2 and insert one measure in front of it.
4. Insert note e in the new measure.

Although the key sig for c minor is now in measure 3, the e in measure 2 is already considered and played as e flat.

Using 048eb7d on Mac OS X 10.9.4


BTW, if you then save & reload, the notes show with explicit flats. Between that and some examination of the code, I take this to make, there is a keysig map that is not updated properly.

Status (old) closed active

This broke again with the fix for #46671: Changing time signature corrupts key signature map, which in turn was caused by my previous fix for #31576: Insert measure in front of score deletes key signature. Quite the mess!

The issue is here:…

I only partially understood the code when I added that comment and made the change I had made from upper_bound to lower_bound. And I guess I *still* don't understand fully. But I can at least explain the comment by referring to this issue. When we insert a measure before a key change, the key change itself currently stays with the measure it originally attached to - meaning it shows up in the score after the newly inserted measure. Yet using upper_bound() in the loop means that the key map treats the new measure (which has the same tick as the original measure) as having the key signature change. That is why this issue exists again - the key map is out of sync with reality for the newly inserted measure.

So, if we want to use upper_bound - which gets the map right - we need to actually delete the key signature from the original measure and move it to this one. Or else, fix the key map here so that it reflects reality.

Title insert measure directly in front of key sig creates measure with wrong key sig insert measure in front of key sig creates measure with wrong key sig; clefs too
Status (old) fixed active

Sorry, the behavior has changed, but it is still incorrect. Steps to reproduce are only slightly different:

1) new score, key of C
2) add Eb major / C minor key signature to measure *3*
3) insert measure in front of measure *2*
4) enter E's into measures 2-4

Result: the E's enter as E naturals in measure 4.

The same bug now exists for clefs. Replace step 2 with "add clef change to measure 3", and you'll see the measure with the clef change also if off in the clef map.

Apparently, inserting a measure *directly* in front of a key or clef change now works correctly, but inserting anywhere else earlier in the score does not.

BTW, I discovered this while adding a regression test. My test just takes the existing insertBfKeyChange() test in tst_measure and adds a loop through the measures to verify the actual key signatures (grabbing them from the KeySig elements themselves) and the keys as reported by the map are in sync for each measure.