Regression - 3.0 doesn’t distinguish between fingerings and LH guitar fingerings.

(edited) Keeping the existing fingerings as they are is an obvious solution. But using the new "L H Guitar Fingering" algorithm, with the addition of an override feature, is also a possibility. See #280088: Improve the L H Guitar Fingering by adding an override option.

This kind of explains why we were previously maintaining the old style default of -0.5sp horizontal offset, though - that's totally correct if we don't do the automatic placement that raises the fingering above the note. Disable autoplace and you'll see the fingering is first being placed directly on the notehead, and autoplace is what is moving it above the note.

Assuming people still agree that LH fingering to the left of the noteheads is the right thing (?), then maybe the solution is to simply change the autoplace algorithm for LH guitar fingering to do nothing but move the finger to the left. So if you want that behavior you get it by default with LH fingering, and if you prefer the above-the-note fingering just use the "regular" fingering element or text style. Seems that covers the needed cases?

I wondered because the original layout was a bit of a compromise, dictated as much by what was possible to do as what people really wanted. At least for piano. So I wanted to be sure before moving ahead with any changes. I'm on vacation and don't have "Behnd Bars" with me so I couldn't check there.

Should be easy enough to do this.

Would also be the time to fix #279113: Fingering: note accidental can result in collision, same issue for piano fingering.

Here is also a chance to improve (?) on 2.x by actually right-aligning fingerings on a chord, like if one note has an accidental and the other doesn't. For that matter, for piano fingerings we could try to stack fingerings for a chord above the chord. Lots of room for improvement here...

Resolving this issue exclusively for LH guitar fingerings is indeed not difficult but, speaking more generally, am I right that MuseScore does not currently have any way for user to specify fingerings placement (except for manual setting their position)? General recommendations may suggest placing them above or left to the note but there are some cases when one would want to place fingerings below notes (for example, if they all are situated in the lower part of staff).

Generally, having such a property in a fingerings style seems to be a more proper solution.

Edit: something similar has been also proposed by @geetar in #280088: Improve the L H Guitar Fingering by adding an override option.

I was looking at this a little last night. One thing I tried was keying off the alignment field (right-aligned = place next to notehead, center = place above). We could also use placement for above/below I guess, or use the top/bottom alignment. If we wanted to avoid introducing new properties for compatibility reasons. But really, why not use the text styles for this? Do we really need two different layout algorithms for LH Guitar Fingering if one is going to end up identical to the regular Fingering algorithm?

BTW, in my trial code (not pushed yet) I have fingering avoid the rest of the note shape during initial layout in Fingering::layout(), then do a second pass in Chord::layoutPitched(0 to align the fingerings with each other. Same approach should work for getting regular fingerings to stack above the chord for multi-note chords rather than forcing these to lay out next to the chord as we currently do.

Text alignment properties still have another meaning, and it may be not obvious for user that the meaning can change specifically for fingerings. If we assign a new meaning for these properties then we may also need to make sure that TextBase does not apply standard alignment options for fingerings. Also import of 2.X scores (and older 3.0 scores?) will need to ignore text alignment properties for fingerings and assign them separately depending on their style. This is a feasible solution but doesn't look clean in my opinion. I can be wrong in that though.

Concerning possible compatibility issues because of the new property, the new property will be ignored by older 3.0 versions on reading a file from newer versions. Layout of left-attached fingerings for single notes is anyway broken for these builds, and we can do almost nothing about that.

I do not propose having two layout algorithms for fingerings but the one that will work properly depending on the fingering direction, be it guitar fingering or not.

Maybe it makes sense to make the whole fingerings autoplacement algorithm work on a chord level as a fingering needs to avoid not only its note or something attached to it but also elements attached to other notes or directly to the chord.

The best solution, IMV, is the one that Cadiz1 has requested: restore the original 2.x "LH Guitar Fingering" algorithm. And fix "Fingering" (this provides placements above/below the note): see #280017: Fingering vertical placement wrong on imported score.

I think there is more to it than that, though - there are also places where regular piano fingers overlap stems and beams, which I assume can also happen with guitar RH fingerings. And would be nice to have better handling of seconds in chords. Also, what about vertical alignment - say, a chord with G# & B, should the LH fingerings be aligned so the B fingering lines up with the G# fingering? And I still wonder if it's worth raising fingerings to always appear in a space rather than on the line. And very certainly, we should be taking both the guitar RH piano and guitar fingers and stacking them above the chord.

Basically, what I'm saying is we have an opportunity to really do things right, let's talk about exactly what that means and do it all all once.

It would be nice to have better handling of seconds in chords:

Yes, see measure 7 in the attached score. And not just seconds. In measures 6, 7, and 9, the Fingering symbols to the left of the chords are overlapping:

Also, what about vertical alignment - say, a chord with G# & B, should the LH fingerings be aligned so the B fingering lines up with the G# fingering?

IMV, auto-alignment seems a reasonable default position.

And I still wonder if it's worth raising fingerings to always appear in a space rather than on the line.

Based on experience of numerous published guitar scores, I would definately say no.

Numerous examples of guitar fingering in the following books: Walter Jacobs, The Guitar Soloist. C J Dorn, Guitar Album.

I definitely recognize the issue with LH fingerings potentially touching each other in chords, but don't have a great solution for that. When I check the literature - including published music as well as guidelines in Gould - it seems there is no real standardization of how people handle this. And it can get pretty arbitrarily complex if you've got, say, a five-note cluster (luckily, such things are exceedingly rare for guitar). I might settle for just emulating 2.3.2 here and letting users make the necessary fine adjustments themselves. One workaround is to choose a smaller font size for these fingerings, another is to create a palette using the symbols in Special Characters / Musical Symbols / Fingering, which I think work especially well at sizes small enough to fit within a staff space.

Anyhow, FWIW I have working code to do most of what I have discussed here. Still a number of rough edges to polish, but as proof of concept, here is what I can do right now:

Sorry, I didn't fully label my example. Fourth measure was two beats of piano, two beats of guitar :-). This is, I believe, the desired behavior in such cases.

And yes, I agree about having a fingering mode (I tried posting this earlier here but it got lost? Apologies for the duplication if it reappears). Hopefully my recent PR to implement that gets merged along with one I plan to submit soon for my current layout work, so the next update for MuseScore will feature really great new fingering support!

(Edited) See post below.

Absolutely, I would still want to fine-tune the offsets. Right now Im just showing the basic placement - above/below, left/right - and making sure we have agreement on that. Sounds like people like the stack of RH fingerings over/nder chords? I have this being identical to the piano alogrithm right now.

Referring to Frederic Noad's "Solo Guitar Playing, Book 2", he places all right-hand fingering just above the stem (for upstem notes) and below the stem (for downstem notes):

IMV, this is the best solution for this particular case.

So, here is an update, I have taken everything about as far as I would plan to for now except for the handling of chords with seconds with LH guitar fingering. See the last chord of bars 1 & 3. "Easiest" solution is for me to just move the whole stack of fingerings over to the left. That is, so the fingerings for the note to the right (as opposed to left) of the stem would be to the right of the other fingerings as well. Eventually it would be nice to have an algorithm to respace the stack of LH fingerings vertically to open up a little space between them, but for now I want to keep it a bit simpler.

Here's my PR:

https://github.com/musescore/MuseScore/pull/4591

And the current results:

While we wait for this to be merged, Windows users can try out the build from the PR itself:

https://ci.appveyor.com/api/buildjobs/7w7u61gs6edajn67/artifacts/MuseSc…

Thanks for testing! Yes, if you enter two fingerings of the same basic type (two LH fingerings or two RH fingers, or an RH fingering and a piano fingering, which at like the same type) then they basically try to avoid each other over and over again and things go badly. Is this something that happens in the real world - having two fingerings of the same type on the same note? I'd be inclined to simply disallow it if not. Otherwise it isn't at all clear what the correct layout should be.

As for the "m" being to close to the beam, yes I see that. The code is trying to avoid the chord but doesn't fully consider the beam. That shouldn't be hard to fix.

See the attached test score. L H Guitar Fingering looks OK, but there are some issues with Fingering and RH Guitar Fingering. For example:

• In measures 1, 2, 10, 11, the numbers are too close to the top staff line.
• In measure 5, 7, the figures on the downstem notes are too close to the notehead.
• The fingerings above/below the beams are too close to the beam.

There also appears to be a bug:

1. Select the staff text labelled "Fingering", set the font to Bold and press "Set as Style."
   Result: Stacked fingering symbols move away from the staff and system distance increases.

2. Set the font-size of the same to 10 and press "Set as style."
   Result: System distance increases.

Every time you press "Set as style" the system distance increases.

Thanks for the input. So, what distance would you consider more appropriate for minimum distance to top staff line or to beam, or for distance from fingering to the downstem notes in measures 5 & 7?

My reasoning in making it tight is to avoid too much extra space being allocated - I'm a bit worried that adding a lot of fingerings is going to make scores much "bigger" on the page. This didn't happen in 2.3.2 because there was no autoplace to avoid collisions or ensure minimum distance to other elements.

IMV, for fingering above beamed upstem notes (2 voices), something like measure 3 of the following:

And for downstem beamed notes (2 voices)—see measure 1. Fingering-to-fingering distance can be tighter than this.

And above unbeamed notes (2 voices), something like measures 1 and 2 of the same diagram perhaps? Ditto, the opposite way. for downstem notes (2 voices).

So, for unbeamed upstem notes like in measure 1 of the above, you want the fingerings to be all the way at the stem end as shown, rather than closer to the notehead as I have it? Do others concur? This is the kind of thing I was trying to avoid, in order to conserve space by default. Gould's examples are relatively consistent about this, if not much else.

Also in that measure, I see the upstem notes the fingerings are centered over the notehead, but for downstem, they are centered over the stems. This seems inconsistent; is that deliberate?

Gould gives some general guidelines but nothing as specific as what we are talking about, and her examples show she really is less concerned with consistency than legibility; there are very few "rules" one can glean from her other than LH fingering to left, RH fingering above and clear of staff.

BTW, I just realized I can't totally disallow two "above" fingerings on the same note, because you can definitely have both a RH fingering and a string number. So, I've got that working, and it also allows two RH fingerings for the same note if you really want. Two LH fingerings on the same note is more problematic, however.

The fingering mode PR is separate, you can test it using the build from that - https://ci.appveyor.com/api/buildjobs/5g1rgcc55tmsf55v/artifacts/MuseSc…. Remember, Alt+Left/Right are the shortcuts to move from note to note. I did try to get Space to work, my first attempt crashed. I'm juggling a whole bunch of things right now, I do hope to look at that again at some point. But Alt+Left/Right should work fine (except for the navigation bug mentioned in a comment above, you should file a new issue for that). So, just enter one fingering, double click it to edit, then Alt+Left/Right to move from note to note entering more fingerings of the same type (LH, RH, String Number, or piano).

Meanwhile, I have pushed changes to the layout PR that address the points raised here. Thanks for the test scores - they are proving useful!

BTW, due to the way MuseScore handles beams, it's not easy to control the spacing to the beam as exactly as I might like, but I've improved it. "Real world" cases of multiple fingerings of the same type on the same note will work OK, some other less-likely cases will result in overlap but at least not the constantly-increasing space.

That build should be available for testing fairly soon. I'll post the link when I can, but here's how to access the build from any PR:

1) view the page for the PR
2) scroll down to the last commit message
3) it will have a green check mark once it has built successfully, orange dot if it's still build, red "x" if the build failed
4) wait for the green check to appear (typically an hour or so after the PR is submitted / updated)
5) click it
6) click Details on the "AppVeyor" line window that pops up when you click the green check
7) click "Artifacts"

You'll then see the link to the build and you can download it from there.

For step 2 above, this is what you are looking for:

You can see green check for the previous commit "update mtest", but there is still an orange dot next to the commit I just pushed, "fixes". When that becomes a green check, you can download.

Here is the link to the current version: https://ci.appveyor.com/api/buildjobs/o1am7g3itufvyf6b/artifacts/MuseSc…

… for unbeamed upstem notes like in measure 1 of the above, you want the fingerings to be all the way at the stem end as shown, rather than closer to the notehead as I have it? …"

Perhaps the best solution in this case is to continue with the 2.x RH fingerings. They are a little further from the notehead.

Also in that measure, I see the upstem notes the fingerings are centered over the notehead, but for downstem, they are centered over the stems. This seems inconsistent; is that deliberate?

This horizontal placement seems to differ slightly from book to book. However, IMV, the horizontal placement in 2.x was OK.

I probably need to clarify again - the "fingering mode" is not part of this layout PR. It is a totally separate PR. So if you want to test that code, you need to downlaod a totally separate build in order to test it. Go to that PR - https://github.com/musescore/MuseScore/pull/4521 -and download the artifact using the instructions above.

I think once you do that, everything will become clear. With that build, there is nothing special you need to do to enable fingering mode, because it isn't a separate mode at all. All I did was make Alt+Right and Alt+Left do nice things while you are in regular text edit mode. So, simply double-click any enter text edit mode just as you normally, then press Alt+Right. It will work just pressing Space in entering lyrics - cursor moves to next note, if there is also a fingering there you'll be able to edit it, if not, a new empty fingering element is created, etc.

If you have further questions about that PR, probably best to continue the discussion in that issue or in the comments for the PR itself, because it's not related to this issue.

Hmm, somehow I must still be failing to explain properly. Have you tried it yet? Not endless double-clicking at all - on the contrary, it is almost exactly what you and others have been asking for! Double click exactly once, then from then on, simply press Alt+Right to enter more fingerings on subsequent notes. No need to double click ever again on that score. Again, just like lyrics - you don't press Ctrl+L for each note, you press it once for one note, and then simply move from note to note pressing Space, entering as many new lyrics on as many notes as you want without ever pressing Ctrl+L again. It's exactly the same way for fingering with the PR I submitted. Double click once for one note, then simply move from note to note pressing Alt+Right, entering as many new fingerings on as many notes as you want without ever double-clicking again. I promise you will not find is useless at all - again, it is pretty much everything you have asked for!

So again, please try downloading the build form that other PR and try it out, then if you have feedback after having tried it, please respond in that other issue - #278175: Easy fingering input mode - or the PR itself. It's an extremely exciting new feature but I need users to actually try it out and give feedback on it.

To whet your appetite, here is the GIF you requested. I actually just fixed it so space works. This video is not sped up, it's real time. In it, I double click the first "1", then within about three seconds, I hit "Space 2 Space 3 Space 4 Space 5 Space 6 Space 7 Space 8" to enter fingerings on the remaining notes.

Useless? :-)

Fixed in branch master, commit 8942ed8a7b

fix #280807: improve fingering layout (for piano & guitar)

In the animated gif, space is added before each fingering. However, this should only be necessary to acheive a certain minimum spacing from a previous element. Above this minimum, no extra space is needed before the fingering.

Thats just how the spacing alogirthm works, not just for slurs but for all elements. Feel free to open a new Suggestion for a spacing algorithm, but please leave this issue as fixed unless you find a specific problem with LH fingering not being treated differently from other fingering as per the subject of this issue.

Automatically closed -- issue fixed for 2 weeks with no activity.