Fingering behaves unpredictably when dragged

• Jun 25, 2019 - 14:33
Reported version
3.2
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.2.0.7412, revision: 2e78246

Open the attached file.

  1. Try dragging any of the "Fingering" numbers in measures 2 or 4 (voice 1) to a new position.
    Result: Fingering jumps unexpectedly when you release it.
  2. Now drag any of the "LH Guitar Fingering" numbers.
    Result: The fingering behaves predictably.

This only affects dragging – not placement via the Inspector.

Attachment Size
dragging_fingering.mscz 9.42 KB

Comments

• Jun 25, 2019 - 15:38
Priority ⇒ P1 - High

I see this occasionally as well, and haven't figured out the trigger - like why does it work fine in measure 1? Seems to relate to the automatic adjustment for multiple voices somehow. Cursor keys also work fine, BTW.

Reply

• Jun 25, 2019 - 18:48

There are no problems in measure 1 because it is all "LH Guitar Fingering." But if you change an "LH Guitar Fingering" number in measure 1 to "Fingering" (using the Style dropdown in the Inspector), you get the same issue.

Reply

• Jun 26, 2019 - 03:57

OK, so I think the problem occurs only if all of the following are true:

1) the fingering is plain (piano) fingering, or RH guitar fingering
2) there are multiple voices
3) the note the fingering is applied to is the only note in the chord
4) there is no beam
5) autoplace is not disabled

These are the conditions that have to be true in order for us the apply the "tight" rule, in which the fingering is kind of "tucked in" between the notehead and stem. In these cases, on each drag, the fingering jumps by same amount as the default distance from the fingering to the notehead.

I'd love it if you could do some testing to verify I have the problem characterized correctly, meanwhile I believe I have a fix for that case at least.

Reply

• Jun 26, 2019 - 10:46

I can confirm conditions 1-5 with the attached MS 2.3 file (take the reset).

Another issue with measure 16: the fingering numbers above the beam appear to be overlapping the skyline of the system above.

Attachment Size
fingering_ms2.mscz 34.7 KB

Reply

• Jun 26, 2019 - 22:23

In measure 16, there is no actual collision, although I would agree the results are bit disorienting. The same can happen with lyrics. It's a tough call because we don't want to add space unnecessarily just because one measure has content way above the staff and another has content way below - if the notes in measure 13 had been in 14 instead, you probably wouldn't have thought this a problem. This could definitely stand more discussion on the forum.

Reply

• Jun 27, 2019 - 11:41

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.2.0.7461, revision: e8d9c80

No problems with this build. Tested by dragging "Fingering" and "RH Fingering" elements in a wide selection of classical scores.

Reply

Fix version
3.2.3