-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable the display of the key signature when changing transposing instruments if score is in concert pitch #25429
Comments
To be sure about what this issue is about. If there is a change of instrument in a stave:
Am I right? |
Just to clarify it a bit (I hope). There (in code) exist a special type of keysignature marked as "for instrument change", which means, it is present there only because of instrument change. There is no need to display souch keysig in concert pitch. But if in the place of instrument change is real key signature, it should be preserved also in concert pitch, no matter, if is the same, as previous one. So we need to disable display of forInstrumentChange key signatures in concert pitch. |
There is a (rare) case where there is no need to show a key signature when changing instrument. For example: score is in F Maj (one flat). Clarinet in Bb part is in G Maj (one sharp). Key of score changes to E Maj (4 sharps), Clarinet part changes to Clarinet in A at the same point. Clarinet part is in G Maj (one sharp). There is no need for a new key signature in the clarinet part. I have actually seen this "in the wild" but I can't at present remember where. Of course, the composer may choose to restate the unchanged sharp key signature in the clarinet part; opinions may differ on whether that would cause more or less confusion. |
I am not sure about this, because there is a key signature at that point, and we do show all user key signatures, even, if they are same as previous one. |
Yes, that is the current behaviour. My point is that sometimes repeating the key signature is not shown if changing the transposition and general key signature at the same point in the score makes it redundant. Since my original comment, I have discovered a workaround as one can make the redundant key signature invisible. So perhaps there is no need to provide a general option to show/not show the key signature to cater for such esoteric cases. |
I am browsing the code to find out where should I change the code. I think it is within the "void TLayout::layoutKeySig(const KeySig* item, KeySig::LayoutData* ldata, const LayoutConfiguration& conf)" method Could you please assign this issue to me to continue working on it? Thanks |
I have done a minimum change to avoid displaying key signatures for instrument change when in concertPitch. Score: Disable KS display concert test 25429.zip NO concert pitch Score view: Concert pitch Score view: (Edited) |
I presume it is ok. I will create the pull request. |
…anging transposing instruments if score is in concert pitch
…anging transposing instruments if score is in concert pitch
…anging transposing instruments if score is in concert pitch
Your idea
I suggest disabling the display of the key signature in the case when the user changes the instrument (transposing) to another, and when the score is shown in concert pitch.
Problem to be solved
It's one thing when the score is displayed in transposed form. Then displaying the key signature change is really useful (and necessary). But when the score is displayed notated in concert pitch, then why in this case display the same key signature that is specified by default in each system?
The situation looks especially ridiculous when a user changes, for example, an English horn to an Oboe. The oboe is not a transposing instrument. Why display a key signature before switching to this instrument?
Therefore, in order to avoid such confusing things, I suggest disabling any display of the key signature when changing any instrument, if the score is displayed in concert pitch.
Prior art
No response
Additional context
No response
Checklist
The text was updated successfully, but these errors were encountered: