Make fingering optional on tab staves

Critical is reserved for crashes and corruption...
For questions please use the forum, feature requests are best discussed there first too.

See Technology Preview Forum and to add a new article there, hit the link near the top

This has been requested several times now. I think we should either not display fingering on tab, or else make it an advanced staff properties setting.

In my view fingering should only be displayed on the notation staff in a linked notation/tablature combination.

Adding fingering to tablature is problematic in that it can easily be misconstrued as fret numbers.

The question is whether it should be an option or not.

If it is decided for it to be an option then my opinion is firmly that it should default to "Display Fingering Off"

In my personal use of tablatures, I frequently use fingering indications. So, I would vote for an option rather than a ban with no alternative.

Also, at least for lute (in whose literature tablatures are a big part), it is frequent to have right hand fingering indications. Support for specific lute RH fingerings has been added recently. Perhaps something similar is true for other plucked string instruments too. I don't think they should be removed from tablatures.

Other ideas?

Thanks,

M.

Errr... not sure I understand:

"fingering on the linked tab staff should be an option" (bold is mine):

why the "linked"? Either LH fingering have a place in a TAB or they have not, regardless the staff is linked or not.

Also I maintain that this exclusion (if introduced) should apply to LH fingerings but not to RH fingerings (or apply separately to either) and I am a little surprised nobody seems to pick this important distinction up.

The problem is that distinguishing between the two kinds programmatically is not easy, unless it is hard-coded to the specific symbols used.

M.

@Miwarre: before responding more fully (but, for my part, I don't think that it is frequent to have right hand fingering indications on the Tabs, I even think the opposite, I talk for the plucked instruments, and in the case of display of two staves, standard and Tab), could you tell me where is the support for specific lute RH fingerings added recently.

I see them nowhere, even with very recent Nightly opened by revertToFactorySettings. Thanks.

https://github.com/musescore/MuseScore/pull/1290/files

EDIT: Oops ... I found them! They are in the Articulations palette, I was looking in Fingering!

I guess LH and RH fingerings are the same element type, but different text styles? And LH are the numbers but RH are the letters? Or what? What about the circled numbers, which I take to be string numbers? Sorry, I'm not a guitarist. I'm actually more concerned with the fact that layout of the circled numbers looks very bad to me.

This point was discussed in this topic:
http://musescore.org/fr/node/32081, especially in the last two or three interventions.

It is a fact that the default position of these strings numbers are far too high now on standard staff.
I just noticed that the layout was different on a Tab staff! And again, and it's screaming, these numbers are quite useless.

Invisibility is a too easy solution, which has its limitations. In wanting to make invisible all kinds of elements on the Tab staff, you end up seeing only this and that ! It is time to do some cleaning! Or to have the choice to do cleaning or not! For me, it's clear :)

I think we do not talk about these strings numbers, and I in particular, because they are far less used (and never in a Tab staff) that RH and LH fingering. There is almost no comparison. This not means that we must forget them, of course, and you are right to remind it.

I think your fingering questions are unrelated to the issue at hand and if my comments don't straighten you out, please start a new thread in the Technology Preview forum to discuss your questions. Ideally with a copy of the score you are having problems with.

Fingerings in 2.0 are not "all over the place" - they are placed quite consistently and much better than 1.3. For single note chords, they are placed automatically in a good location, usually above the notehead or stem. They should not need further adjustment. The only fingerings that are placed directly close to the notehead will be for multi-note chords, because those are too hard for MuseScore to figure out automatically. This is exactly like 1.3. But unlike MuseScore 1.3, these fingerings will respond to changes you make in your Fingering text style.

Again, if you are still having trouble, please start a discussion in the Technology Preview forum with an attach a copy of the score you are having trouble with so we can help further.

Above the note is definitely much more standard for single notes. And realistically, at least for piano music, fingers tend to be written in much more often for single note passages than for chords. So it's important, I thin, to get single-note fingering "right" as much as possible. But chords are harder to solve. Having them automatically appear further to the left of the note is one possible solution, but I guess the decision was made to keep the 1.3 behavior and the user come up with his own plan. There is definitely still room for improvement there, and elsewhere there are some existing discussion of possible improvements to the automatic fingering algorithm that you might want to resurrect and contribute to:

http://musescore.org/en/node/32081
http://musescore.org/en/node/32086

BTW, I think we don't currently have issues filed for either of two problems that have been raised:

1) copy and paste of fingerings does not preserve manual adjustments
2) string numbers are placed in a way that seems to make no sense

These issues are discussed in those other threads. Could someone with a good understanding of the desired behavior please post issues for these?

What are the reasons Marc which explain that this issue has been demoted as a lower priority in the Hit List?

My original hope was see this for the Beta 2, as I wanted Beta 2 to be "feature complete". But there will be no more betas, so there is really no particular reason to prioritize it more highly any more. I'm now trying to focus attention on crashes, corruptions, bugs that render a given feature all but useless, layout bugs that cannot easily be worked around, bugs in delicate areas of code that carry high risk, etc. This is not to say that the other bugs are worth fixing before release - just that given they didn't make the beta 2, it really doesn't matter so mch *when* they get looked at.

Realistically, as a feature request, this could still be added post 2.0, but I do still think it makes sense to add before release if we can.

Agree with you to keep the focus on the issues that are intended to maximum stability of 2.0. This would be a great reward for all if this target is reached or approached to the highest level possible.
While hoping that this feature request does not drag too long: it has been widely discussed there are several months now :)

I know we're looking forward now to finally see the release of version 2.0.

My intention is not to delay it. All my continued support, since x months on the Issue Tracker, shows otherwise, I think you will agree with that.

I reopen this thread because:

1) I just received a file from a correspondent of a guitar forum (delcamp.net, which has an international audience). I bring my help, and this correspondent, like others I know, prefer this rather than using MuseScore forums. It is their right: they play guitar, and they ask questions about MuseScore via this guitar forum on a thread dedicated to them.

This correspondent, who converted to MuseScore (from GP) uses linked staves. This is what we get:

Is this really what we want as result? This "dirty" Tab staff? And notice that there is no unisons that should hide more so. Fortunately, I would be tempted to say …

2) because the coincidence is not accidental, I realize that over the months, I completely abandon this "Linked Staff" feature. What is my interest indeed, to use it, if I have then to go through a workaround (ie add a no linked Tab saff, make a copy-paste through the filters selection (F6) ) to eliminate unnecessary fingerings, strings numbers etc.

And yet, I was always used this feature by starting and testing the “2.0” via the nightlies. It is to say...
So many efforts have been made for this feature, powerful and attractive (in a first intention) And many efforts were needed to solve many of the issues raised by it. I remind each of one I think… All this for that, I have trouble believing.

Indeed, it works too well, alas. Everything is linked. Everything, it's the word. Even the undesirable, superfluous, redundant (fingering, you guessed)
We rested too easily on the "Invisible" feature but which is, ultimately, a stopgap. Because it does not prevent the display, on the MuseScore file, of an unpleasant result to the eye.

Options have been added recently for historical Tabs. It's a good thing. But I think this “fingering option on Tab staves”, for a more large number of users maybe, was at least as essential.
So, go to the next if not 2.0, at least 2.1?

Thanks for your reading.
 And kudos to all for this 2.0 incredible project whose birth is approaching now :)

My understanding is that most people probably don't want fingering on tab staves most of the time but some might. The right solution is probably to add an option to the staff properties to control whether fingering is displayed, just as we have for stems etc. But if we wanted to avoid another option, what if we simply made fingering not be linked? So if you want it on a tab staff, you add it manually to that staff rather than rely on the linking. I haven't totally thought this through; it's just a suggestion.

I have a rather simple and cheap PR ready which simply hides fingerings in TAB, once they find their way into it, regardless of the way this happens. Example (quickly contrived, I apologize for unidiomatic details):

NOT FOUND: 1

Pro: fingerings would still exist (the linking stuff is not touched at), but would have no visible avatar (I mean literally nothing, not a bunch of greyed out numbers). This would make easy to link the hiding/showing to an option, should this option been added in the future.

Con: manually adding fingerings to a TAB would still be a successful operation, but with no visible result: i.e. the fingering would be added, but would not show up.

If this is considered enough for the moment being, I can post the PR.

Later, adding the option could be considered.

P.S.: as it can be seen in the example above, lute-specific RH fingerings are NOT hidden (luckily they are not considered fingerings by the programme!).

Thanks for adding the attachment. It helps. The result is as expected: "no visible avatar (I mean literally nothing, not a bunch of greyed out numbers", as you say well :)

But I do not understand what action, concretely, should be done to achieve this result?

If the result is OK and nobody complains about undesired side effects I have not thought of, I will push a code PR to the main repository and, hopefully, it will be merged sooner or later to find its way into the main code.

My post was a request for comments, before pushing the PR. Right now, there is nothing you can do, I'm afraid.

It doesn't affect me one way or the other. My sense, as I said, is that msot people just don't want fingerings on tab; you (Miwarre) were the main proponent of it as I recall. So to me, simply disabling it from being displayed is fine if you are OK with it. Sounds like the fact that lute-specific RH fingerings are not included in this satisfies your use case or you wouldn't be proposing the change?

@Marc Sabatella, re #25: indeed. I'm happy with it.

And, if an option to turn fingerings display in TAB's on or off at will, is later thought to be necessary, it will be rather easy to implement, just a matter of adding one more condition in two if's (and the check box in the UI of course).

So, I'll push the PR.

We did make some deliberate changes to default fingering positions between beta 1 & beta 2, to try to meet the conflicting needs of both guitar and piano. It's not perfect, but should indeed be a lot better for most of the cases where the defaults were not good for particular use cases. See http://musescore.org/en/node/36846 for the discussion.

I don't know enough about it to say whether or not it is common enough to be worth adding by default, but do note you can customize the palettes by creating your own workspace ("+" button at bottom of palette) and Ctrl+Shift+dragging elements into it. So you can have "T" or any other "unorthodox" symbol you like.

Fixed in 507aa6cd01

Result as expected. Thanks :)
Compare the result now with image of same file in comment #20. Really better, right?!

I'm quite interested why the glissando in that image isn't slanted.

Drag from your score. That is, create an element in your score and set it the way you like it, then Ctrl+Shift+drag that to the palette.

Feel free to ask on the forum with specific instructions as to how to reproduce the problem you are seeing. Right now, I don't understand what you might be doing wrong or if there might be some sort of bug somewhere.

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

How did you do that? No fingering in tab, looks great. Please reply ASAP!