Spurious key change after transposition

• Dec 21, 2018 - 10:48
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0., revision: 3543170

I attached this sample score created with the compressed SATB template. Note the changed key in the first staff.
keys-before-instrument-change.png

Repro steps

  1. Open attached score
  2. Right click first staff
  3. Staff properties...
  4. Change Instrument...
  5. Woodwindws > Alto Saxophone
  6. OK

Expected: The first staff is now B major in all systems.

Actual: The first staff in the second system is A minor rather the B major. The last barline in first staff changed to double line.
keys-after-instrument-change.png

Workaround: Drop any key at the wrong key in the first staff of the second system. Thereafter select the wrong key. Thats selects the key signatures in both staff 1 and 2. Press delete.

Attachment Size
keys-instrument-transpose.mscz 4.84 KB

Comments

• Dec 21, 2018 - 20:35
Status duplicate ⇒ active

While it seems to be fixed for the repros steps above it is not for this.

Repro steps:

  1. Open the score
  2. Select all of first staff in both systems
  3. Menu Tools > Transpose...
  4. Transpose > Chromatically > By Key > Closest > F Major > OK
  5. Right click first staff
  6. Staff properties...
  7. Change Instrument...
  8. Woodwindws > Alto Saxophone > OK

Expected: The first staff is now D major in both systems, when Concert Pitch is unchecked.

Actual:

  1. The first staff in the second system is F major rather the D major.

  2. The last barline in first staff changed to double line.

    keys-after-instrument-change2.png

Reply

• Dec 22, 2018 - 06:12
Title Key change in second system after set transposed instrument ⇒ Spurious key change after transposition with local / polytonal key signatures
Priority ⇒ P1 - High

I can confirm. After some playing around, I could reproduce similar effects a couple of ways, but only when using "local" key signatures (eg, like this example, where there are different concert keys in effect at the same time). Still not good, but maybe something to look at more a little later.

Reply

• Dec 31, 2018 - 15:47
Title Spurious key change after transposition with local / polytonal key signatures ⇒ Spurious key change after transposition
Priority P1 - High ⇒ P0 - Critical

See also https://musescore.org/en/node/280914#comment-882337. It contains a score (created in 1.x) where you can reproduce the same basic issue even though no local key signature is involved, but also involving both an instrument change and a transposition.

1) load attached score (accept the reset)
2) change top staff to baritone oboe (probably any transposing instrument)
3) reduce scaling to 1.374
4) transpose entire score to key of F using Tools / Transpose

Attachment Size
The_Swan_.mscz 24.95 KB

Reply

• Jan 18, 2019 - 18:48

Copied from #282071: Changing to enharmonic key signature reverts automatically.

To reproduce the issue, create a score with an alto Sax and apply the Key of E major to it. You will get the key of C# Major as expected.

Change to the key of Db, following the instructions in the how to at https://musescore.org/en/node/260491

Press the concert pitch button twice and the key signature is back to C#.

If you have a C instrument in the score also, unneeded key signatures are inserted where there were system breaks before pressing concert pitch twice. I saw this when I started with a blank score using letter sized paper.

One other thing. at the end of the first line on the sax, there is a courtesy C natural key signature and it is acutally applied to the part.

Marc S wanted to make sure this issue is fixed at the same time.

Reply

• Jan 18, 2019 - 19:01

I have a sense that all the examples in this thread stem from the same underlying problem and would all be fixed by the same code change, but it is definitely important to test each of these cases. If nothing else, changes to fix these are almost certainly all related and should be considered together.

Reply

• Feb 12, 2019 - 23:51
Status active ⇒ PR created

There have been many reports of this type of problem, so I can't guarantee they all stem from the same cause. But the cases I am looking at come down to one simple thing: when we transpose the generated key signatures at the beginning of each system, they remain marked generated (as they should be) but we also add an event into the keysig map, thus turning them in "real" key changes, so they continue to appear even if the layout changes (as it often does) and they are no longer at the beginning of the system. And since they are marked generated they can't be deleted.

So, I have two potential fixes, each quite simple.

Fix strategy #1 is to make sure we don't add the event to the keysig map when transposing these generated keysigs. We continue to transpose them, they continue to be marked generated, but now they can be cleaned up normally on relayout.

Fix strategy #2 is to not bother transposing them at all (and thus not adding them to the map either). Since they are generated, they are going to get regenerated on layout anyhow (and perhaps in different locations), so transposing them is wasted effort. This is actually the strategy used when you toggle the concert pitch button - any generated keysigs we encounter, we just skip. And so far, this has not lead to any problems that I can recall.

Either way, we do need to be careful to still do the right thing when transposing a selection that happens to start with a generated keysig - in that case, we do want to transpose that initial keysig.

I'll submit a PR for at least one of these.

Reply