Fingering behaves unpredictably when dragged
P1 - High
S3 - Major
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 18.104.22.16812, revision: 2e78246
Open the attached file.
- 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.
- Now drag any of the "LH Guitar Fingering" numbers.
Result: The fingering behaves predictably.
This only affects dragging – not placement via the Inspector.
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.
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.
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.
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.
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.
Here is a Windows build of my PR, would appreciate help testing, both whether this fixes it, and also whether it causes any new problems, It should only affect the behavior in that specific case.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 22.214.171.12461, revision: e8d9c80
No problems with this build. Tested by dragging "Fingering" and "RH Fingering" elements in a wide selection of classical scores.
Which is to confirm that Marc's PR fixes it, right?
That's why I posted the revision number: to make clear that I tested Marc's build and not a previous nightly.
Fixed in branch master, commit 215bd271bf
fix #291287: fingering jumps on drag in 'tight' context + collect_artifacts
Fixed in branch master, commit 7117cc77bb
_Merge pull request #5178 from MarcSabatella/291287-fingering-jump
fix #291287: fingering jumps on drag +collect_artifacts_
Automatically closed -- issue fixed for 2 weeks with no activity.