MuseScore incorrectly applies accidentals in some key signatures
When inputting notes via MIDI, one would expect that the nature of the key signature should determine whether a given accidental is entered as its sharp or flat version.
In other words, generally speaking, in sharp key signatures accidentals should default to sharp, and vice-versa for flat key signatures.
MuseScore mostly applies this rule of thumb correctly, with 4 notable exceptions:
In the key of G major, A# defaults to Bb
In the key of F major, Gb, defaults to F#
In the key of F major, Db defaults to C#
In the key of Bb major, Gb defaults to F#
The attached pdf shows a score I used to test all keys from 1 to 6 sharps/flats, where I identify the incorrectly applied accidentals in red. The first bar of each key signature shows the normal major scale for that key, and the second bar shows an adjusted scale where each possible accidental has been entered and left in its default state.
I'd also like to point out that I'm talking about the default behaviour I believe MuseScore should apply - this is not to say that you shouldn't be able to, for example, have a Bb in the key of G major - by no means whatsoever! But I do believe that MuseScore should default that note to A# in G major as it does in all other sharp keys.
I'm not sure what the thinking behind the current algorithm is, but my humble suggestion is that there should at least be a setting called, say "Accidentals default to sharps in sharp keys/flats in flat keys" that can be switched on to enable this behaviour.
Without such a setting, note input in some keys can become quite frustrating, having to constantly leave note input mode, select individual notes and hit J to respell the pitch, go back into note input mode, and so on - especially when inputting chords.
| Attachment | Size |
|---|---|
| Accidental_Test.pdf | 27.74 KB |
Comments
Your algorithm fails badly for minor keys (which are pretty popular). Now I'm not saying you can't have a Gb in G minor (See "O große Lieb' ", St. John Passion), "by no means whatsoever", but F# ought be the default....(and, of course, a MIDI inputter cannot distinguish between Bb and G minor).
In reply to Your algorithm fails badly… by [DELETED] 1831606
Sure, there are plenty of examples where this behaviour would not be expected - harmonic minor keys being one of those. Natural minor keys wouldn't be affected one way or the other. In such a case, you wouldn't want the setting I'm talking about to be switched on.
In fact, maybe it would make more sense to have a drop-down list where you can select a template that works for you, one would be the kind of approach I'm advocating for, another might be harmonic minor, other modes might also be options. For those who care for such a feature, surely it would make life much easier when inputting notes via MIDI.
Another approach might be that MuseScore remembers the last time you applied respell pitches to a given note and gives you the same note next time you input it, saving you from having to do it again.
Yet another approach might be that MuseScore constantly analyzes the accidentals applied within any one key signature and intelligently predicts what the user expects based on what's already there.
In reply to Sure, there are plenty of… by jayceepooze
Real compositions rarely can be assigned to a "subspecies" of "minor"; features of the "different minor scales" are employed in their course.
But all of these proposals, esp the dropdown, are extraordinarily reasonable IMO. "Respell pitches" "needs therapy", too (see other discussions). It is not harmonically intelligent.
In reply to Sure, there are plenty of… by jayceepooze
I feel the dropdown would be kind of overkill and still not very effective - no matter what algorithm is chosen, it's going to be wrong a very significant amount of time, which is one reason I don't find MIDI input very valuable. But if you do use it, you simply have to resign yourself to need to correct spelling of pitches, a lot.
On the other hand, the idea of remembering last-used is good, especially within a single measure that should be a no-brainer. I think there might be an existing issue for that...
In reply to I feel the dropdown would be… by Marc Sabatella
My proposed dropdown would be tuning-pegs in a nonequal-tempered system. Perhaps an image of a piano octave with three ticks on each piano-key allowing you to specify what it should be called until changed. Can't fail.
As noted elsehwere, I don't think this rule of thumb would be advisable to follow. It's guessing no matter what, but I prefer an algorithm that guesses right as often as possible. The "prefer flats in flat keys, prefer sharps in sharp keys" would guess wrong far more often than the current algorithm. The current algorithm is based on the circle of fifths, we prefer spellings that are more closely related to the key. Think of the scale as being seven adjacent notes on the circle, then we see where the others are. In the key of G, we cover the range from C to F# on the circle. Bb is only two "ticks" removed in the flatter directly (first F, then Bb). A# on the other hand is four "ticks" removed (C#, G, D#, A#). I won't claim this is completely optimal, but it does actually work pretty well for the most common cases.
In particular, considering your example, I do suspect Bb is very likely more common in G major than A# is. Logic (as per the above) tells me it probably should be, and my experience suggests this is probably true. Feel free to do a statistical analysis of published music if you wish to convince anyone otherwise :-) Actually such a thing would be not hard to program in a system like music21.
In reply to As noted elsehwere, I don't… by Marc Sabatella
Musescore knoweth not between G major and E minor. One sharp is one sharp. In G major, Bb is more common. In E minor, A# is more common. A piece in E minor is less likely to have sections requiring Bb than a piece in G is likely to have sections in e or b minor requiring A#. Point is, any nonconfigurable "rule of thumb" is DOA.
In reply to Musescore knoweth not… by [DELETED] 1831606
Actually, there is a dropdown in the Inspector (added a couple of updates ago) where you can select between major and minor (or other modes!) for key signatures. But it's just there for MusicXML export, it isn't used by the spelling algorithm. And of course, pieces in the key of "one sharp" seldom stay in the major or minor exclusively, but commonly modulate betwene the two, and other keys. So really tying this to the key would be impossible.
What I'd claim is that you can delete the word "nonconfigurable" from your sentence above and it remains just about as true - any algorithm at all is going to be wrong, a lot. You could spend your time trying to second guess the algorithm but fiddling with dropdowns, and then still spend addition time fixing accidentals, or you could just spend your time fixing accidentals without first fiddling with dropdowns, and I'd claim it would be a wash. No algorithm would ever be right enough to make a difference. But I'd ba happy to be proven wrong with an empirical study.
In reply to Actually, there is a… by Marc Sabatella
Oh, I disagree. "Configure it as the key roams" is not an algorithm, but an approach, as is "adjust each note". I agree, though, that fixing one accidental manually and letting the choice persist ("last used") approach (not "algorithm") might do equally well. It's not magic; relative locality of key is fundamental.
In reply to Oh, I disagree. "Configure… by [DELETED] 1831606
"Letting the choice persists" has the immense advantage of the simplicity.
And could actually be much easier to "use" (nothing to configure) than regularly having to change one or several options.
In reply to "Letting the choice persists… by frfancha
It effectively is changing one or several options, but in a natural way, as it were. I'm sold, let it be (or B♭),