Notes not entered in first measure entered into wrong octave
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
In the attached score, Haydn 8th symphony.mscz
In the Oboe, enter a G into a measure besides the first.
Result: you get a G3
Expected: You get a G4.
All notes not entered in the first measure are between G3 and F#4, an octave below what is expected.
With further testing I see in the attached score, all treble clef notes appear an octave low, bass clef notes appear an octave high and alto clef notes are displayed as expected.
Fix version
3.0.5
Comments
So you mean, the octave that is initially chosen when using keyboard entry? I assume this is due to something on the invisible staves, and also is probably related to if not a duplicate of #283514: Some notes randomly jumping to top octave when input. I guess the algorithm for determining the initial octave is relying on some bad data in some cases.
In reply to So you mean, the octave that… by Marc Sabatella
I made all staves visible with the same results. It seems to be based upon the clef and the fact there are no notes before it it in the system. As I've been working on the score I realize that the first note in every system that is not in the first measure acts the same.
What I mean is, it.seems.likely to be a result of the notes in those invisible that is somehow setting the default, not the mere fact the staves are invisible.
Anyhow, I've curious about this glitch a while now, maybe today is finally the day I look...
OK, I think I understand the problem. The algorithm normally starts backtracking from the cursor to find the previous note on the staff, and assuming it finds a note, it will use that as a starting point and then pick the closest pitch. But, if it finds a clef first, it gives up looking for a previous note (which may well be in a totally inappropriate octave for the current clef) and instead chooses a note that makes sense for the clef.
This is all well and good and I think would produce good results in most cases, but it fails here because the algorithm doesn't see the initial clef except when starting in the first measure. That's because the initial clef is represented differently from clef changes. So we think there is nothing to base our decision on and pick the closest note to middle C.
It's an easy fix if we agree the goal of the algorithm is good (and I think it is).
Your analysis seems to cooberate what I see when I enter notes and agree that the note entered should be on the staff if there are no notes on it previously.
https://github.com/musescore/MuseScore/pull/4735
Fixed in branch master, commit 8fb9db7d1e
fix #284886: wrong initial octave for first note
Fixed in branch master, commit 0fac294142
_Merge pull request #4735 from MarcSabatella/284886-initial-octave
fix #284886: wrong initial octave for first note_
Fixed in branch 3.0.5, commit 61e86e77f7
_Merge pull request #4735 from MarcSabatella/284886-initial-octave
fix #284886: wrong initial octave for first note_
Automatically closed -- issue fixed for 2 weeks with no activity.