Note entry sometimes chooses wrong octave

• Jul 13, 2020 - 12:24
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
MuseScore

Steps to reproduce:

  • Open the attached file
  • Click the top-left note in the first bar of the piano right hand (the high A)
  • Click somewhere in the second bar of the cello at the bottom-right, but NOT on a note or rest, so that the whole bar gets selected.
  • Press C to change the existing note E to a C (do NOT switch to Note Input mode first)
  • Observe that the resulting C note is one octave above middle C, which is completely out of the range of the existing cello part, and therefore a bad choice of octave.

Now repeat the experiment except this time first select the F in the left hand of the piano rather than the top A. This time the resulting C will be the octave below middle C. This is a much more logical choice which I would expect regardless of which note was previously selected, because it's the closest C to the F previously written for the cello in the first bar, and in the majority of scenarios parts employ voice leading for smoother melodic progression.

I find the current behaviour very hard to explain. If the octave is chosen based on which note was last selected rather than which note precedes the note being changed within that part, then it would explain why the high C is chosen in the first experiment, but not why the low C is chosen in the second.

Another oddity is that if no note is selected prior to selecting the second bar in the cello part, then pressing C with Note Input mode disabled does nothing! Why would it change the note some times but not others? But maybe that's a separate issue?

This is with the latest Linux AppImage:
OS: openSUSE Tumbleweed, Arch.: x86_64, MuseScore version (64-bit): 3.5.0, revision: b5add95

Attachment Size
note_entry_octave_test.mscz 5.17 KB

Comments

• Jul 13, 2020 - 17:08

The algorithm is, we look backwards from whatever note we start with, looking for a clef. That's why the results differ depending on which staff you choose. So the issue is really, why are we trying to start from that staff at all. Probably clicking the note sets the track for the input state but clicking the measure does not.

The relevant code is in Score::cmdAddPitch(), if someone wants to look at this. If it's as simple as update the track for input state when making a range selection, that's probably trivial and pretty safe. Of course, if your range selection is more than one staff, all bets are off as to which staff to use. Unfortunately we don't actually know which staff will actually get the note because we aren't in note input mode yet, this all happens before that.

Reply