# Notes not entered in first measure entered into wrong octave

• Feb 26, 2019 - 19:26
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.

 Priority ⇒ P1 - High

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 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.

 Status active ⇒ PR created
 Status PR created ⇒ fixed

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_

 Status fixed ⇒ closed

Automatically closed -- issue fixed for 2 weeks with no activity.

 Fix version ⇒ 3.0.5
Fix version
3.0.5