Inconsistent octave selection in note input mode

• Nov 3, 2018 - 20:27
Reported version
3.0
Priority
P2 - Medium
Type
Ergonomical (UX)
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

Notes are supposed to be entered into the nearest octave to the last note. Currently several of the note combinations are wrong, while others are correct. In this picture

note octaves.PNG

you can see the bass clef notes that are entered by default in the key of E-flat. In the key of C, the results are as expected

note octaves 2.PNG

The key should not affect this since it's 6 half steps up from A-flat to D-flat and 7 half steps down. It is the exact same distance from A to D and from E-flat to A-flat in both directions.

It seems this also happened in previous versions but I wasn't able to determine when it selected the wrong octave.


Comments

I remember looking at this some time ago. The issue as I recall was that the way note input works, at moment you press a letter key, we haven't calculated yet whether it might be flat or sharp (due to the key signature or an earlier accidental), so we are actually always calculating relative to the plain "white key" note. So potentially (probably about half the time) wrong results are obtained if the about-to-be-entered note is a "black key". Something very much like that anyhow. I think I may have tried out some sort of hacky heuristic to improve the odds of success, but my memory is very fuzzy here.

In reply to by Marc Sabatella

I have a fuzzy memory of discussing this once before as I stated. If the current key signature were taken into consideration then the future application of an accidental becomes irrelevant. The key signature isn't even ignored or both the key of C example and E-flat example would have the same results.

I don't know what kind of complicated logic is leading to making the wrong decision, but it should be a simple case of is place the note in the current octave less than 7 half step? If so, then just enter the note. If it's more than 7 then move the note to the farthest adjacent octave to the note. So if you enter a C5 then an F, F is more than 7 half steps from C, since F is higher than C, move the F to the octave in the opposite direction which is down to enter an F4. Since it probably uses the midi pitch number then enter the F that is pitch of the F in the same octave minus 13, to find the proper pitch number.

This logic is slightly simplified because there has to be a conversion from midi pitch to octave number and back to midi pitch, but that can't be too big of a deal.

My recollection is that the key signature is ignored when it comes to guessing what the pitch of the note about to be entered is. The previous note has already been entered, so no guessing involved, and the key signature has already been taken into account.

So for instance, key of C, you've entered a B and then you type E. MuseScore knows the B is a B natural. When you type "E", as I mentioned, currently MuseScore does not attempt to guess whether that will result in a E or Eb or even E# - the answer depends not only on the key but also which octave it ends up choosing and whether there is an accidental on that note in that octave earlier in the measure. So it just guesses E natural, and calculates that the E natural above the existing B is closer, so it picks that, enters the E, and this does indeed turn out to be an E natural, so this turns out to be a good decision.

On the other hand, in key of Eb, MuseScore still makes no attempt to guess whether typing E will result in a E natural, Eb, or E# - again, the answer depends not only on the key but also on which octave it ends up choosing. So it just gives up and guesses E, which is silly because it would be better to guess Eb to at least be consistent with the key, but that's what it does. It then calculates that E natural is the same distance from Bb whether you go up or down, so it's a coin toss, and in this case, down wins, and it tries to add the E below the Bb. At this point, it finally discovers that adding an E on that line yields Eb (in this case because of the key), so picking down turns out to have been a bad idea.

The simple but not totally correct improvement would be to at least consider the key when guessing what note would be added when you type "E". Then we'd know ahead of time that typing "E" would probably yield Eb when in the ley of Eb, and we'd correctly choose to add it above the Bb.

So it's a bit of a chicken and egg problem - until we know which octave wins, we don't know for sure what accidental would be applied, which throws off the distance calculation, causing us to pick the wrong octave sometimes. But if we at least took the key into account, we'd guess wrong a lot less often. Then it would only be accidentals earlier in the measure that would cause us to sometimes guess wrong.

In reply to by Marc Sabatella

I believe taking the key signature into account would be preferable since, as you said, it would be correct in choosing the closer note more often. I don't mind the coin toss always deciding on down, it's better than a random coin toss. Getting a consistent result makes it easier to know if I'll need to use ctrl+arrow immediately upon entering a note to move it to the correct octave.

Severity S4 - Minor S3 - Major

In this video, I selected the rest, pressed E (on the alto clef) then D. Notice the octave jump because it crossed the bar line. This doesn't happen if there is no bar line and clef has no effect.

octave jump.gif

Since this is part of the same algorithm I'm putting this in the same bug report so maybe they will both be fixed at the same time.

That case looks like a true bug, not just an inherent chicken-and-egg limitation in the algorithm. But I can't reproduce. I tried creating a score with alto clef, four sharps, entered E then D across a barline as you did, but got the expected result. So here we'll need the score itself.

In general, videos are nice, but sample scores are still a good idea if it's anything more than a single measure that is obvious how to enter from scratch.

This has happened consistently in this score and other places. I actually found the issue on the Cello staff, then tested it on the viola staff. I'm very aware that pictures aren't always the best way, but I didn't think it was score specific, especially since it was seen on multiple staves and I've noticed it before. If I can reproduce the problem I'll post steps. Until then...mysteries in the deep.

It was mentioned that the nearest-note logic should account for the key signature, but why should this matter? Shouldn't it just be based on the number of lines & spaces a note would jump (e.g., avoid jumps larger than a fourth)? Anyway, here's the result of typing "EBEBEBEB" in note entry in the key of C major vs. E-flat major:
MS3_nearest_note.png
I'm not sure why key signature should be affecting the logic here since the interval is identical between E-B and Eb-Bb.

The issue with key is, until we actually add the note, we don't knownthe exact pitch. We need to look at the key as well as earlier accidentals in the measure to known the pitch you'll actually get when you type a letter. So it's a chicken and egg question. Does that make sense? I can try to explain in more detail if not.

Btw, I see what S. Christian is saying, instead of trying to pick the closest note chromatically, we could just count lines and spaces. This would just change the specifics of which cases we get wrong, though, if one is expecting a true "closest" note.

In reply to by mike320

As I understand it, MuseScore will try to add the entered note at the nearest interval to the preceding pitch, correct? This means the largest interval jump should be a fourth. Accidentals have no bearing on what is considered a fourth--interval is determined entirely by the note letter names. A up to D is always a fourth on the staff, and accidentals only determine the quality, e.g. perfect, augmented or diminished. The distance in lines & spaces will always be the same. Unless I am misunderstanding something, I don't understand why accidentals should have any bearing on MuseScore's nearest-note logic.

The algorithm is chromatic - in other words, based on number of semitones. That is why both key signature and accidental status are relevant but unfortunately are ignored currently.

Maybe it would be better if we switched to "dumb" algorithm based on lines and spaces only?

In reply to by s.chriscollins

Marc, in what scenario would a note be chromatically closer when added in one direction while actually creating a larger note-name interval? As far as I know, the only way to achieve this would be a double-sharped fourth or double-flatted fifth, but I can't imagine any scenarios where this would be the correct spelling. Nor can I imagine a user being unforgiving when his double-flatted interval wasn't the one chosen by the note entry logic.

The obvious case to me is a score in E that has a Db (due to an accidental) and then you type G - or any transposed variation. So sure, a doubly-diminished fifth, and not worth worry about.

I'm fine with someone re-implementing the algorithm to work that way, it would solve the key signature issue and only break cases no one likely cares about.

In reply to by Marc Sabatella

Since an heuristic can only go so far, it would be nice to be able to explicitly control the direction without moving back to the note. I.e., have prefix keys meaning "up/down relative to the previous note", or commands meaning "move the previous note up/down an octave" (which would allow adjustment without going back to the previous note during note entry), or modifier combinations (shift, control, etc) to specify the direction during note entry. I'm a new user, so I imagine there is an answer for this, or else it has been discussed before. Apologies if this is a dumb comment.