Accidentals constantly requiring respell

• Apr 30, 2020 - 01:18

Hi there,

I'm working on a piece in the key of Bb major that frequently requires Gb accidental notes to be entered. My understanding of the way accidentals should work by default is that if you're in a flat key (Bb major for example), accidentals should default to their flat version, vice-versa for sharp keys, no?

It's pretty frustrating - every time I input a Gb, it defaults to F#. If I'm inputting single-note lines, it's not too bad because I just press J after I input the note, but when you're inputting chords it's a real pain. I have to leave note entry, select the one note that needs respelling, press J, go back into note entry and continue.

I've been searching up on whether or not there's a setting that allows you to prefer flats or sharps, but so far I haven't been able to turn anything up except people telling me that MuseScore is supposed to just get it right based on the key signature, however this is clearly not the case in this example.

Is there anything I can do ?


Comments

In reply to by frfancha

Here's an example. It's in the key of Bb major. Bb major is a flat key, meaning all accidentals should automatically default to flats.

By default, Bb Major has Bb and Eb in its key signature, leaving 3 potential black note accidentals: Db, Gb and Ab.

Db correctly defaults to Db (not C#).
Ab correctly defaults to Ab (not G#).
Gb incorrectly defaults to F#.

My input method is MIDI keyboard in Note input mode.

Attachment Size
Accidental_Test.pdf 10.9 KB

In reply to by jayceepooze

I was more expecting a true musical extract in which musically Gb is expected instead of F#, rather than a theoritical scale.
Would you mind pointing me on some musical theory explaining why probability of Gb is greater than probability of F# ?
Because actually from midi input MuseScore can only generate the most probable accidental and can't guess the correct one in 100% cases.
I wonder what makes you think that Gb would be more frequent than F# in Bb major.

In reply to by frfancha

I mean... sure... I've explained this twice now already, but ok. It's fine.

You're aware that some key signatures use flats and some use sharps, correct? Sharp key signatures are (major keys):

G,D,A,E,B,F#

Flat key signatures are:

F, Bb, Eb, Ab, Db, Gb

If a key signature is a sharp key signature then any accidentals should default to sharps. It makes it easier to read if you generally speaking stay within either the realm of sharps or flats. So for example, in the key of D, if I play the black note between G and A, MuseScore should default to calling that a G#, not an Ab.

It's just basic common sense. Generally speaking, in flat-based key signatures, you want your accidentals to default to flats, and in sharp-based key signatures, you want your accidentals to default to sharps.

I hope that makes sense. I guess if MuseScore doesn't do this by default then I would strongly suggest it should be added as a feature. I'd actually go a step further and consider it a bug that it doesn't work this way by default.

In reply to by jayceepooze

You have explained absolutely nothing.
You are just repeating the hypothesis that Gb is more frequent than F# in Bb major.
That's possible (however I strongly doubt that), I was curious to see which basis (other than personal judgement) you had to support that.
(And yes I known pretty well music theory and harmony otherwise my question would be meaningless that's for sure)
By the way, I don't have a midi device to try it, but in G major, what happens when you enter a [A# = Bb] ?
I would expect to get a Bb by default even though key of G major contains a #.
Why? Just because probability to write that sound is higher as Bb than A#, that's all

In reply to by jayceepooze

You honestly believe that this is about frequency? Not at all. This is about generally staying within one realm - sharps or flats, depending on key signature. I'm not sure where you came up with the probability calculation regarding Bb verses A# in the key of G major. G major is a sharp key, so accidentals should default to sharps.

In any case, it should definitely be a setting that you can switch on or off.

Also I should point out that it doesn't matter how "musical" the extract I show you is, MuseScore doesn't seem to care whether you input a note on its own, what other notes are around it, whether it's part of a chord, what the chord sequence is, or any other variable you care to think of. All it evidently cares about is the key signature when it decides whether to display it as a sharp or a flat. That's fine! That's great! But it's just not getting it right 100% of the time.

I've gone a step further and created a document showing where MuseScore gets this right and where it gets it wrong, for all key signatures up to 6 sharps/flats (beyond that we get into double sharp/flat territory which doesn't really apply to what I'm talking about).

The first bar shows the major scale for that key. The second bar shows the same scale with every possible note changed, to identify where MuseScore correctly and incorrectly sticks to the nature of the key signature when calculating what accidental to apply.

So for example, in the key of G major the notes are: G, A, B, C, D, E, F#. Modifying every note to its potential sharp key (ignoring white note sharp keys, B# and E#) gives: G#, A#, B, C#, D#, E, F#. Musescore gets all of these right, except instead of A# it defaults to Bb.

I've highlighted in red the notes where MuseScore gets it wrong - there are only 4 in total.

Attachment Size
Accidental_Test.pdf 27.74 KB

In reply to by jayceepooze

Actually you will see that there is indeed a quite active and supportive community on this forum, and all people doing that for free and on their personal time.
It is very infrequent that you have to wait more than some hours to get the info you need.
Hopefully some of them will soon answer and explain better than I was able to do why the behaviour of MuseScore makes sense.

In reply to by frfancha

It is quite common for music in a major key to modulate temporarily to the relative minor. G minor is the relative minor of Bb major. The seventh degree of the harmonic minor scale has to be raised by a semitone relative to the key signature. This is important as it resolves upwards by a semitone to the tonic in a perfect cadence for example. The seventh degree of the G minor harmonic scale is F# not Gb.

How's that?

In reply to by SteveBlower

Yes, we can sit here all day and think up examples of where this rule of thumb should be broken. I'm not sure how helpful that is though.

Again, I'm not advocating that this should be a hard and fast rule, just a setting that can be enabled and disabled for the DEFAULT behaviour, and if there are cases where it doesn't work, the setting can be turned off.

In reply to by jayceepooze

Complex, lengthy pieces in which a given accidental is one way for sections in one local key and the other way in another section in another local key are too numerous to mention. There is a measure of the organ solo in the second mvt of Cantata 146 where Db and C# appear (correctly) in the very same measure in the same part for the same pitch (m 72):
BWV146.2_72.png
A piece in Bb major of any length (at least in Bach or later) will have sections locally with allusions to Bb minor, or Eb minor as well as other sections with the earmarks of G minor, D minor, or C minor. The idea that "one size fits all" goes nowhere. A dropdown-menu with "what would you like for now?" is right.

In reply to by jayceepooze

Well, when someone posts a problem they are having, it is a common practice on this forum to ask a few questions.
1. We would like a MuseScore file that demonstrates the problem. As well as what you were doing when the problem happened.
2. OS and version of MuseScore.
There's more, but this basic information is critical to quickly helping us understand what it is that is happening to you. Yes, you explained it. You assumed that it was a coding problem. However, I can't tell you how many times one of us has loaded a score from someone with a problem not only to find some kind of corruption, but some sometimes not able to reproduce the problem at all.
So the thread became one about theory.
You told us that you use a midi keyboard. I input notes with a mouse. As a result, I don't have your problem. In your scenario, to add a Gb I have to hit the b button and click the G. Or I add the note G followed by "down arrow" (G becomes F#, then the "up arrow" ( F# becomes Gb). I also don't have to leave note input mode to change anything, like a chord, because I can enter it properly as I go.
I'm not in the least saying you shouldn't use you Keyboard. Only that there are a multitude of things to consider when seeking and giving help. As well as the written word completely failing, sometimes.

In reply to by [DELETED] 1831606

@BSG Oh, I completely understood his issue, and was answering one of his questions. And acknowledged (by way of a little humor) that i don't have the same problem because my note input method is so slow, awkward, and inefficient that I just don't have a problem with incorrect notes. Unless I enter them incorrectly. Fortunately, I write mercifully simple music that doesn't require me to know if I need a Gb or F#. Or Or key signature, or most note values.

My two cents:

MIDI is not a great input method for exactly this reason, software will need to guess the correct spelling, and unfortunately that's just not possible to determine reliably. For me, computer keyboard entry is faster. The downside is then MuseScore needs to guess octave, and that's also going to be wrong sometimes. Such is life!

Anyhow, when it comes to guessing, I disagree with the statement "if you're in a flat key (Bb major for example), accidentals should default to their flat version, vice-versa for sharp keys". The correct spelling depends completely on the context. For instance, when occurring as chromatic passing tones, we spell with sharps ascending, flats descending. Or, when the note is a chord tone, we spell according to the chord. Eg, D major has an F#, Eb minor has a Gb.

If we always defaulted to flats just because the key happens to contain flats, we'd guess wrong a lot more often than necessary. We want to guess right as often as possible. And that means considering the actual relationship of the note to the key and the frequency of use.

In the key of Bb major, F# and Gb are actually both pretty common. F# occurs as the third of a D major chord which is V/vi, Gb as the third of an Eb minor chord which is iv chord. Both chords, while not seen every other measure, are seen often enough that it might be a coin toss. But, the fact that a key signature of Bb might actually mean portions of the music are actually in the key of G minor is what seals the deal. F# is the leading tone, and will occur far more frequently than Gb. People would complain bitterly if their G minor pieces kept having Gb instead of F#. So, that breaks the tie.

In reply to by Marc Sabatella

Good point. I was going to say that Gb is the flat 6th in the key of Bb, whereas F# is the sharp 5 which would line up more with the idea of if being an augmented 5th, but as you point out it may depend on any given chord's function at the time. It may be a situation of a temporary key change. Music notation has many subtleties and Musesore has a tremendous amount of automation which at times is nice, but on other occasions completely annoying. As an end user, it is hard to understand it from the programmer's point of view. Actual ease of use for the end user may cause enormous problems for the programmer, particularly when the program stepped off on the wrong foot years ago.

In reply to by gBouchard

I think you're confused about what programming is. The assumption that it guesses wrong accidentals because "it's very hard for the programmer; I'm an end user" is wrong. OK "end user", what would you have it do if the first black note you play in a key signature of two flats is the one between F and G? Is it F# or Gb, or "the programmer should figure that out". No, sorry, no programmer can figure it out if no human can figure it out. Programs can't read minds, especially, if like 3/4 of the people posting on MuseScore, the user doesn' t really understand the difference between F# and Gb. "This choice is impossible, in the abstract to determine, without user help" does not equate to "the programmer is stupid or lazy". One can only program processes one can imagine or describe one's self; in fact, that's exactly what programming is.

And what on earth do you mean "the program stepped off on the wrong foot years ago"? That it's basically bad, a wrong design, a screw-up, has horrible, fundamental flaws that have never been addressed or fixed? What the "heck" are you doing here using it if you feel that way about it? What do you mean by "stepped off on the wrong foot years ago?" Please explain this damning, pervasive critique.

Do you still have an unanswered question? Please log in first to post your question.