#1629 Notation Editor: Can't move note to desired pitch

[Mark R. Rubin]

The Notation Editor sometimes behaves strangely, only allowing an existing note to be moved two scale degrees away from its current pitch instead of arbitrarily.

Steps to recreate:

1. New RG document, create one bar long segment, open in Notation Editor.
2. All default settings (G clef, C major key signature, etc).
3. Switch to draw tool, create quarter note E on lowest line of staff.
4. Switch back to select/move tool.
5. Try to move note to D on first space below staff. Cannot be done, note jumps to middle C.
6. Move note to middle C and release.
7. Note can now be moved to desired D.
8. And then back to E, but after that again not to D without first moving to middle C.
9. Move note to F on lowest space in staff.
10. Now cannot be moved to E without going first to D.
11. Many other similar: Can move higher on staff and release, and then back to E or other such pitches.
12. Note can be moved from E to D (first through Eb) using the keyboard down arrow key. Up arrow key also works correctly.

Seems to be independent of font size, zoom, note spacing, note duration, key signature (happens at different pitches), etc.

Can anyone else reproduce this? Is it an artifact of font rendering on my Linux distro? (See FR #505). Is there something about music theory I don't understand, that one shouldn't change from E to D in the same piece? ;)

Tested with RG builds of several recent 22.06 pre-release commits including [abdf22], [8c1c6b], and further back. Does not happen with 21.12.

[Yves Guillemot]

I confirm this bug.
It exists for years.

[Mark R. Rubin]

Thanks, Yves. You are right and I was wrong -- the bug is in 21.12, just happens at a different place on the staff and seemingly more random (E to D works at first, then not after moving note around). So maybe 22.06 is "progress". :(

[Philip Leishman]

A quick look at this - the problem seems to be in StaffLayout::getWeightedHeightAtSceneCoords. According to the comments this is very approximate!!
I switched to floating point arithmetic and it seems to work now. It is still more difficult to move a semitone - I believe that is the whole point of this routine - but it is now possible.
See merge request.

[Mark R. Rubin]

Thanks Philip! Not so much for me because I mostly use the Matrix Editor, but for the thousands of Notation users who I understand have put up with this bug forever. Why they didn't complain about it is beyond me.

Your patch works perfectly in my testing. It even does the correct thing when moving the inner E in a root position C major triad to D, offsetting it to right of the C. As far as moving chromatically by a semitone, it seems to me that the design intent for moving notes with the mouse is that they stay within the scale defined by the key signature -- that moving by a semitone to an accidental in the key intentionally requires using the keyboard arrow keys. At least that's how the current code works except where it was broken and couldn't even get to in-key notes in some cases.

[Mark R. Rubin]

Oops, just found a very small problem: Create a Csus2 chord (treble clef, C major key signature) C-D-G low-to-high starting at the C above middle C on the third space from the bottom on the staff. Change to the select tool. Select the D note.

Now try to select the C. Assuming the cursor "hot spot" is at the tip of the arrow, it's very picky about where the click is in relation to the note head. Especially if the font size is increased (maximum 16 in a default build on my distro, I've increased it in my code, see FR#506) the C can only be selected by clicking slightly outside the note to its upper left.

A bounding box problem in the RG code, or is this directly handled by Qt? I'm somewhat familiar with selection issues regarding QAbstractGraphicsShapeItems in the Matrix Editor but don't know anything about how fonts are drawn and/or selected.

[Philip Leishman]

OK - this is a separate issue.
Very complex code !!!
The problem is in NotationScene::setupMouseEvent
I believe the note head shift is to the right if the stem is up and to the left if the stem is down.
Only shift right was correctly accounted for.
I have made a change - please merge again.

[Mark R. Rubin]

Philip Leishman wrote:

Very complex code !!!

Yes, I've been noticing some of that in RG. :(

Thanks for the fix. I've tested and didn't see any problems even when torturing it with clusters of notes on both sides of the staff, sharps/flats, beams, etc. I can't guarantee I tried everything but what I did couldn't break it. :)

[Ted Felix]

Works much better. This always drove me crazy. It's still a bit finicky on certain notes, so more work is needed in this area.

Merged as [20731a]. Please test latest git.