Custom key signature - if there are different accidentals in different octaves, they are not aplied to score
S5 - Suggestion
If there are different accidentals in different octaves, only one affects all octaves.
This kind of key signatures are ofen used in scordatura scores.
This kind of key signatures:
is in score interpreted like this:
but it should be:
The way would be have option to "per octave only accidental".
Or less flexible, but still usable, if there are more accidentals, than one, set it "per octave".
Key signatures generally give accidentals that are valid in all octaves, that much is by design.
Here MuseScore gets contradictory information on what an 'unadorned' F should be, depending on the octave, but only 2 out of 9 possible octaves are given, so an undorned F4 should be a natural F, but an unadorned F5 should be an F#, what about F-1 to F3 and F6 to F9, which should those be, F nattuarl or F#?
This is a problem impossible to solve.
In reply to Key signatures generally… by Jojo-Schmitz
I think, it is possible to solve this by option "per octave".
Lets say, we have this signature:
If both are selected as "per octave", then F1-F3 and F6-F9 are natural, F4 is flat and F5 is sharp.
If F# is "global" and Fb is "per octave", then octavs, except F4 is sharp and F4 is flat.
Only one can be set as global (and doesn't need to be).
This way, I think, it covers all situations.
If I remeber correctly, once upon a time, when custom keys started in MS, it was always "per octave" only.
Key signatures, in general, are not by octave but affect all notes in all octaves. No reason to make custome key signautes to be different.
A single accidental, which is valid throug the rest of a measure, is a different thing and whether that should affect only that note in that octcave or all of them
In reply to Key signatures, in general,… by Jojo-Schmitz
I agree, in general it is so, and it is no reason, to be different in custom Keys in general.
But in some situations, it requires different behaviour.
Thats why I ask for option.
In scordatura scores, it is common to have such signatures.
Workround could be to hide incorrect accidentals, but is requires lot of custom corrections.
Well, no, you reported it as a bug and even as a major one. It is not, it is by design.
But even as a feature request, AKA Suggestion this just won't work (and get closed as "Won't fix"): which of the 2 accidentals in your example is the rule (for all octaves) and which the exception (just for the octave it is notated in)? How would a (real human) musician tell them appart?
So actually the only possible fix is the workaround, and even that is very questionable, as the musicians still won't get the composer's intention.
a concept like "a red accidental in a (custom) key signature means that it applies to this octave only" is, as far as I can tell, unheard of. And would get lost on a B/W printout too.
Maybe an accidental in brackets/parentheses would be understandable though?
In reply to Well, no, you reported it as… by Jojo-Schmitz
Sorry, if I reported it incorectly.
Red is not meant to be printed, I just paint it here, just you can see, how it could work.
Program knows, which is rule and which is one octave (becouse one tick it).
I dont think, program(er) needs to care, if program allows to product score, which can be unuderstendable by reader.
I think, good program allows writer to write anything, he wants, (even stupidities).
And good writer wouldnt write, what is not clear.
But also, this examples are not so unuderstandable. In scordatura scores, it is quiet common - you can see Biber: Mysteries.
In these scores, there is also a bas, where a standard signature is present. That tells you key of song.
So musician knows tonal space. (And tonal space set by key signature means, you ar without accidentals in measures.)
OK, as compromise, I can live with second rule I wrote: if there is more than one (different), it means "per octave".
Well, let's see whether someone is willing to implement it.
See https://github.com/musescore/MuseScore/pull/10549 for master (MuseScore 4)
(see https://github.com/musescore/MuseScore/pull/9000 for 3.x)