Tablature fingering order not always correct

• Mar 10, 2021 - 21:14
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
fixed
Regression
No
Workaround
No
Project

Create a guitar/banjo tablature. Enter some 3 note chords. Set the RH fingering on all 3 notes: p i m

So far so good.

Now make the middle note a higher pitch than the top note - fingering stays the same.

Notice the fingering is now: p m i

It appears that the fingering/text stacking order is based on pitch, which works great for music notation but doesn't always work for tablature. It's really bad for 5-string banjo tabs where the 5th string is higher than the rest. In tab, the fingering stacking order needs to be based on string number.

Attachment Size
fingering.PNG 5.06 KB

Comments

Frequency Many Once
Status active needs info

AFAIK fingering is just text attached to notes, no semantic behind it, so won't and can't react on pitch or string changes. So this wozld not bw a bug but rather by design

In reply to by Jojo-Schmitz

Workaround No Yes

In the example I gave above, the only way to get the fingering to appear in the right order is to assign the wrong fingering to the top 2 notes. When you enter the fingering properly (p,i,m) you get (p,m,i). It is most noticeable in 5 string banjo tabs where this bug shows up all over the place because of banjo 5th string.

I think somewhere along the line the notes are sorted by pitch (maybe in a chordrest) or somewhere. This done by design in music notation, but by mistake in tab. However, the workaround is to enter the wrong fingering for notes in chords and let Musescore sort it into the correct display order.

In reply to by laturetab

Workaround Yes No

One last note on this. The fix should happen in layout.cpp at around line 4255. The code needs to change to look something like: if (tab) {...} else {do what it's doing.} For tab, need to sort fingerings by string number.

Good analysis, I think you're right. The fingerings belong to the notes and their offsets are thus calculated relative to the notehead, and but it happens during chord layout so that we know the positions of all notes before starting. And yes, I think it's just a matter of making sure the fingerings are sorted correctly before laying them out.

@laturetab , have you contributed to MuseScore development yet? This would make for a fantastic first PR!

Severity S5 - Suggestion S3 - Major

This is definitely a bug, and it is pretty major, as far as fingering layout is concerned. And @laturetab is quite correct about the simplest way to solve this. The implementation of this idea is rather straightforward as well. But I wonder if it wouldn't be better to make sure that chords on tab staves are sorted properly to begin with. Then it would not be necessary to sort the fingerings each time during layout.

Yes, it might be best to sort the tab chords this way in the first place, but who knows how many other places in code might rely on the current system. Any number of loops during the layout as well as in commands like those for changing pitch or strings might be affected. I also wonder about the comment pointing out line position isn't necessarily known yet, but my guess is that applies more to standard than tab staves. Anyhow, long term that's probably better indeed, just riskier and requiring more extensive analysis & testing.

In reply to by Jojo-Schmitz

I just found another thing this change in sort order fixes. Guitar/banjo strums (arpeggio) are played in the Chord sort order. So if you strum up on a 5-string banjo you should hear the 5th string last (i.e. the highest pitch). You hear it first. If you strum down, you should hear the 5th string first, but you hear it last. If you apply @mattmcclinch fix for fingering you also fix this strum problem and things start to look and sound better. I'm not sure if Matt is going to PR this fix -- it definitely has my vote.