Changing to enharmonic key signature reverts automatically
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
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.
This is marked major because there is no workaround.
Fix version
3.5.0
Comments
It seems the same issue came up in https://musescore.org/en/node/282129
If I understand correctly, this is not a regression, but was that way in 2.x as well, correct?
I have this marked critical mostly on account of the extra key signatures on the other staff. But that is probably a duplicate of #280390: Spurious key change after transposition.
Regarding the basic issue of enharmonic key signatures, we really need to support this more directly (eg, via a a property set on the key signature itself, or a staff property, or a style option). The steps in that howto worked in 2.x but really that behavior could just as easily have been seen as a bug in the first place.
See also #39176: Option to convert transposed instrument key signatures into enharmonic equivalent when number of accidentals exceeds limit
One way or another I'd very much like to see a good solution here, open to discussion as to what that would look like.
In reply to If I understand correctly,… by Marc Sabatella
In my specific test described above with a Flute and Alto Sax, pressing the concert pitch button twice changed the starting key signature back to it's other enharmonic, but inserted a C-major key signature at the start of the next system. This is most definitely a bug. I'll leave that to you to determine if it's a duplicate, though I have my doubts. This is definitely a regression whether the version 2 workaround is by design or not.
I think a staff property with radio buttons that give the user the option that says
Key signature prefers * Sharps * Flats
(* is a radio button).
and gives uses the proper enharmonic key signature as necessary in the score. It will get complicated when it comes to handling accidentals, but I would be happy if it did the equivallent of down followed by up arrow for sharps and up followed by down arrows for flats to prefer the same type accidentals as are in the key signatures. This would of course not affect notes entered after the option was changed.
I would actually prefer to see this in the Key signature inspector, so you can adjust these on a key change by key change basis. In that case, all that would need to be changed in the score is the key signature and you could leave the responsibility of respelling pitches to the user. IMHO this would be quite sufficient.
I am, let's say, 80% sure that the bug with extra key signatures when a C instrument is also present is a duplicate of #280390: Spurious key change after transposition, because both rely on transposition of the key signature for a single staff. In any case, it's much more related to that than to what happens when you toggle concert pitch. So I'd encourage you to post your steps to reproduce in that thread so when that bug gets looked at, your case is considered as well
Meanwhile, though, the behavior described in this bug - about what happens when toggling concert pitch - is not a regression.
I am inclined to believe that a property on the key signature makes the most sense. A complication is that clicking one key signature currently selects them across all staves, which is deliberate to facilitate a subsequent double-click of a new key signature in the palette or to make courtesy signatures all appear/disappear together. But Ctrl+click works to select just the current staff. And, maybe, if the option is constructed well, it won't hurt to set it even for instruments that don't need it. That is, if the option is "prefer flats" and there is a threshold of 5 sharps (I'm thinking both controls are needed), it won't won't kick in for the trombone in the key of E concert but will for trumpets and saxophones, etc.
In reply to I am, let's say, 80% sure… by Marc Sabatella
The bug wasn't present in version 2 and it is in version 3. I thought that was the definition of a regression.
As for making my radio button suggestion global, that's not such a good idea. It often more desirable for the Bb instruments to have flats, while the Eb instruments have sharps. You will also have problems with your trombone example because there is a Cb key enharmonic with B. The prefer flats/sharps option would always and only be considered if one of the standard enharmonic key signatures were available for the given instrument.
An even better way to handle this, in my opinion, would be to allow users to enter a transposed local key signature into a score. If I want Db for my sax I enter it, if I want C# I enter that.
Another nice option would be to insert the transposed key signature into an instrument and the others adapt appropriately. So dragging a D to the alto sax will put G in the Bb trumpet. This would help with the less educated budding composers or the over educated ones who don't realize MuseScore transposes automatically. This option is a bit off topic from the given issue though.
Well, I'm still trying to understand. I thought in version 2, toggling concert pitch on and off did revert the key signature, and that was one major limitation of that technique? Are you saying this didn't happen?
If you're just observing that in version 2 we didn't also see the bug of extra key signature appearing on other staves, then indeed, that unrelated bug is a regression, but again, it's more related to #280390: Spurious key change after transposition than to this bug. Let's keep this bug focused on what it says in the title - what the reverting of the enharmonic spelling. Which, as I understand it, is not a regression since 2.3.2 behaved the same.
OK, so I can see why the global property for key signatures is not good. But Ctrl+click would solve it, since it selects on only one staff, Whether that's "discoverable" enough is open to debate, but this is going to be a fairly obscure feature anyhow.
I like the idea of entering the locally transposed key signatures, and really, we can almost achieve that already. Some people are surprised that key signature has to be entered in concert pitch - while this seems "obvious" when working on a full score, it's less so when working on a single part. I'm not crazy about special-casing parts, or scores of one staff, to disable the transposition of key signature, but disabling it on Ctrl+drag from the palette (or Ctrl+double-click) seems quite reasonable. That would, in about two lines of code, provide a very simple way to get the desired enharmonic key signature, although we'd still have to deal with the bug (also present in 2.3.2., right?) where this gets lost on toggling of concert pitch. Fixing that might also be not too hard if we allowed for key signatures of up yo 8 or 9 sharps and flats internally, and had toggling concert pitch actually use those as appropriate. Hmm, we could even hack things so those always displayed as enharmonic equivalents, although that is pretty hacky really.
Version 2.3.2 kept the enharmonic key signature no matter what you did short of manually changing the key signature. I've used my method enough that I would have found a bug if it existed.
Any method you choose to change the spelling of an enharmonic will have to be taught and should not terribly likely to be done by accident, since this would cause undue confusion.
OK, thanks for the update. I would have sworn it was the case that toggling concert pitch destroyed it and therefore we were advising people to save this for the end. Maybe I'm thinking of a different workaround that was formerly recommended?
If I understand the steps to reproduce the issue correctly, it still appears to be in 2.3.2 version. Am I correct with the following steps?
1) Create Alto Sax score, apply E major
2) Transpose by key below to B major
3) Transpose by interval up by perfect fourth
4) Toggle Concert Pitch 2 times
With these steps the displayed key signature reverts to C# major both in 2.3.2 and current master. Still I was testing on 2.3.2 which comes with Debian, so it might contain some differences from the officially released 2.3.2 version.
https://github.com/musescore/MuseScore/pull/5500 will probably fix this issue too, in addition to #288495: Allow user to select flats or sharps for enharmonic key signatures
https://github.com/musescore/MuseScore/pull/5500 has been merged so user now can choose enharmonic key signature explicitly (in Staff/Part Properties dialog), without the need for the procedure described in https://musescore.org/en/node/260491. Therefore this bug should be not actual anymore and, I believe, can now be closed. Any issues for with the new setting are better to be tracked separately.