Fingering: position resets to default when symbol is pasted to another note.

• Nov 1, 2015 - 15:16
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

MS 2.0.2 / Nightly d45cc19 / Win 7 / Win 10.

Most of the fingering symbols do not retain their user positions when the number/letter is copied from one note to another. Use attached score:

1. Open advanced workspace "Fingering" palette.
2. Apply "fingering 1" to the C in bar 1. Drag the number to a new position and then copy it to the same note in bar 3.
Expected result: User position should be copied to new note.
Actual result: User position is reset to default.

3. Repeat step 2 using "rh guitar fingering," and "string number". In both cases:
Expected result: User position should be copied to new note.
Actual result: User position is reset to default.

Note: The correct behaviour is shown by "LH guitar fingering": the offset position is copied to the new note.

Attachment Size
fingering_offsets_not_copied.mscz 19.81 KB

Comments

• Nov 1, 2015 - 19:35

See #32086: Repeating fingering manual adjustment. It seems I fixed this at one pont, but then maybe something else changed to cause the fix to no longer work. It only happens to work for LH Guitar Fingering because there is no automatic fingering at all for that fingering style - the text style settings are honored directly.

The original fix for the copy/paste issue was here:

https://github.com/MarcSabatella/MuseScore/commit/84b179cc45b352ddc71ae…

The idea was to not apply the automatic layout of layoutFingering() if the user offset was non-null. However, it is always null upon copy/paste from what I can tell. So I think somethig must have changed further upstream. Maybe we switched from writing "offset" to writing "pos" tags or something like that. I will try to investigate more as I can, but if anyone else wants to take a look, be my guest.

Reply

• Nov 7, 2015 - 07:27

Seems that somehow, adjustReadPos() was formerly being called by this point, but now it isn't. Adding a call right at that spot where I check the offset fixes the problem, but probably that's not realliy the right solution. Still investigating, but if anyone has any ideas about changes to when adjustReadPos() is called for pasted elements, that would be helpful.

Reply

• Nov 7, 2015 - 17:04

adjustReadPos() is normally called only at the end of layout, which would not have happened yet. So I'm actually a bit confused as to how this could ever have worked. Hoping to get some confirmation as to whether it in fact did ever work after the aforementioned fix from last October, and if so, at what point it stopped working.

Meanwhile, a safer fix seems to be to check both userOff() and readPos() to be sure both are null before calling layoutFingering() to do to the automatic positioning. But I'd still like to understand better before pushing that change.

Reply

• Nov 7, 2015 - 19:20

Currently (2.0.2, or more recently), the result is this one (see image below), ie, the offset position by user is not preserved after copy/paste for: RH fingering, String number, Fingering (optimized for piano), but works for LH fingering.
currently.jpg
- From what I see, this result has always been the same since the merge of these two commits on November 1, 2014: https://github.com/musescore/MuseScore/pull/1388
The image below was made with this Nightly (same result few days later, etc.) : 1d02427
1 novembre.jpg

Reply

• Nov 7, 2015 - 19:27

OK, thanks, so it looks like my fix never actually worked. Based on my reading of the code, this seems expected. I'm still wondering how we failed to notice this before, but anyhow, I'll push a real fix soon.

Reply