Ties and slurs have a mirror effect by entering two voices in Tab/standard linked staves

I believbe this is connected with the issue reported in https://musescore.org/en/node/69821. The tie behavior actually seems correct if we accept that voice one really should have stems down and voice 2 stems up if the the stems are set to down in staff properties. The question is, I guess, whether that really makes sense.

If I understand correctly, this bug (as well as other recently filed bugs) only affect multi-voices in simplified tab styles.

My first reaction is to consider them more or less "By design": let's be honest, the simplified tab styles are not made for complex part writing. If you need it, go for the full style (which I tend to assume to work correctly in most cases, correct me if I am wrong).

This added to the fact that often changes made to fix bugs in standard staves are not checked for side effects on tab staves makes rather difficult to support tab in a consistent way.

Any practical suggestion, anybody?

Thanks,

M.

Right now, the default setting for "Stem position" in the Staff Properties / Advanced Style Properties / Note Values is "Below". If it were "Above", you get the results you want, as far as I understand.

Unfortunately, for the "Simple" styles, this option is greyed out, so you cannot even change it directly. But you can trick MuseScore into allowing you to change it by first setting "Shown as" to "Stems and beams", then setting it back to "None" after changing the "Stem position" setting.

I think that just changing the default for this option in the "Simple" styles would address the concern here. What is a little less clear is what to do for the "Common" styles. Would people object to the default being changed to "Above" here? It seems that would make sense to me *if* you planned to write in multiple voices - voice 1 would always be above the staff rather than sometimes above, sometimes below as I guess it was before. But if you are planning on using only one voice, you might prefer stems below? I honestly don't know, but at least there is an option to control the behavior.

If people *really* want it so that voice 1 stems in "Common" are below the staff if only one voice but above if there are multiple voices, I guess maybe there could be an additional checkbox to force this behavior. Assuming it doens't make sense to simply revert the change in #63561: TAB - Modified stem direction - don't work properly - I didn't really understand that issue in the first place. But the fix sure *seems* logical to me.

@cadiz1, #5: "if you consider this behaviour "by design", I agree to classify it in this status, even I preferred the previous, really more expected.". This was my first reaction, but I am open to suggestions.

The feeling remains however that we are stretching the TAB notation well beyond its (intended?) meaning and possibilities. Putting it in other words, as I have repeatedly said, standard and tab notations are two different notation systems, not two typographically different ways to organize the same data.

Changing one into the other requires a level of translation, it is not a mere transcoding but requires some guesses and "user mind reading" so to speak (a programme can transcode an Arabic sentence into Roman alphabet, but it cannot really translate it into, say, English, as Google translator proves abundantly).

"See this score [...]: the standard staff allows to define the polyphony movement , while the Tab staff helps for deciphering (for those who have difficulty reading the notes)."

I understand and I agree with the usefulness of this approach and its common usage. However, this is probably one example (an easy and frequent one!) of what I am saying: if the user needs a full notation with all "the bells and whistles" on one side and an abridged notation on the other side, he has to expect that the programme can only go to a certain point in guessing what the user expects.

If full control over both versions is needed, the only way which can be expected to fully work is using two unlinked staves.

@Marc Sabatella, #6: "Unfortunately, for the "Simple" styles, this option is greyed out, so you cannot even change it directly."
Those "simple" styles have no stems at all! So, enabling stem position seemed not to make sense; in fact it is true that stem direction brings with itself a number of other positions (like slurs and ties).

So, it might sense to enable stem position radio buttons even for the no-stem styles; would it be helpful or it would simply puzzle the user?

"But you can trick MuseScore into allowing you to change it by first setting "Shown as" to "Stems and beams", then setting it back to "None" after changing the "Stem position" setting." Did you try? I am not sure it would work.

Yes, I get why the "Stem position" option is greyed out for "Simple" styles. So I am not actually proposing changing that - just changing the default for this option. Indeed, perhaps even changing the code to force this option to "Above" if "Shown as" is set to "None", so existing scores are automatically fixed, and this loophole closed.

I did try the method I suggested, and it does currently work - at least for the specific issue of slur directions - and it seems to survive save / reload.

But there is still the issue of "Common" style to resolve.

UPDATE: This is what I have understood so far about the previous steps:

The original issue (#63561: TAB - Modified stem direction - don't work properly) was about two different things:

1) stem position not affected by tab config radio buttons ("Above" / "Below"): actually the OP was a special case involving voices; as (then) expected, voice 1 stems were always above (and voice 2 stems always below) regardless of those radio buttons. The issue was further obscured by the fact that, in the supplied example, voice 2 happened to have no stem at all (only whole notes), so the only appearing stems (those for voice 1) seemed not to respond to the stem position setting (well, they didn't, but the were expected not to!).

2) The lack of stems in voice 2 left an extra empty space below the staff (where stems would appear, should there be some).

lasconic agreed that 2) was a bug and proceed to correct it (the change in measure.cpp of //github.com/musescore/MuseScore/commit/33797cd6c55490cd67a3267e5e7e09f409e61dbf ).

But apparently, he also corrected 1) (change in chord.cpp of same commit), which was probably a bit premature.

So, it might make sense to revert change 1) (to get back the original stem behaviour) and leave in place change 2) (to keep the proper spacing when stems are not there).
(huuufff...)

Comments?

Miwarre: what you say about keeping one change but reverting the other makes sense, but then, so did the fix itself! Still seems somehow we are missing something. If there are really people who want the old behavior for "Common" styles where stems for voice 1 are below staff if there is only one voice but above if there are multiple voices - which seems highly illogical to me - maybe there should really be a third option for "Stem position", or an additional checkbox. So that one could choose between the following behaviors:

1) voice 1 stems always up, voice 2 stems (if present) always down
2) voice 1 stems always down, voice 2 stems (if present) always up
3) voice 1 stems down if it is the only voice, up if there are multiple voices

#3 is, if I understand it, the old behavior. The question in my mind remains, is this really a more sensible default than #1?

1) Re non-linear relation between standard and tab notation: I firmly believe tabs are NOT made for multi-voices; we may try to accommodate them in tabs with some trick, but they do not really fit and there will always be 'unexpected' side effects or inconsistencies.

Assuming we could find a reasonable setup for voices 1 and 2, what about voices 3 and 4? Sooner or later someone will complain about stems for them and what could we do: 3D stems, raising out of the score for voice 3 and sinking into the score for voice 4? We have to stop somewhere...

Looking at historic tab usage, in a time when tabs were made by professional composers for professional players (so, no abridging or summarizing there, but the full pieces as intended), we see no track of voice writing at all (beyond the occasional 'tenues').

And, @cadiz in #11: it is true that the result you currently get could be improved; but it is also quite reasonable to assume that, if you in the tab are after an abridged or simplified version for the beginner, it would be appropriate to give up voices and write all notes in strict temporal sequence (as F. da Milan most likely did in the source...; the standard staff would help understanding the voices), giving up linked staves. This is an example of what I mean by the notations not being mechanically transcodable one into the other and of the limitations of linked staves.

2) Re default for "Common" styles (better: style with stems present and beside the staff), @Marc Sabatella, #12: your 3) might be a more sensible behaviour, as notes of part 1 tend to be 'above' and notes of parts 2 tend to be 'below', so each note would be nearer to its own stem.

For sure 2) (which is more or less the current behaviour after the 'fix') is the less sensible of all, as it disjoints notes from their stems.

However, I would reword that setup as: "for single voice, stems follow the "Above / Below" setting; for multiple voices, voice 1 stems are above, voice 2 stems are below".

3) In summary, my current proposal is still to:
3a) revert changes to chord.cpp in the above mentioned commit;
3b) look if the 'no stem' style could made use of a more sensible (implicit) stem direction for the use of slurs and ties.

Note that:

3c) another user is complaining about the current 'inversion' (stems disjointed from notes in multi-voice);
3d) the case who prompted that 'infamous' commit was obscured by the fortuitous lack of any stem in voice 2 and chances are that that OP would not have noticed anything strange, if his voice 2 had had some stem.

I have partly reverted and party corrected the changes of the commit quoted above, arriving at this result:

NO STEMS AT ALL:
NOT FOUND: 1

STEMS BELOW:
NOT FOUND: 2

STEMS ABOVE:
NOT FOUND: 3

Does this looks correct or at least less unexpected? In case, I am ready to push the PR.

I don't quite understand the comment about measure 3. You picture shows a chord with two slurs, which is non-standard - normally chords get only a single slur regardless of how many notes are in it. If you add multiple slurs to the same chords for whatever reason, it is indeed expected they would all be added on the same side and you would need to flip them if you wish them on opposite sides.

I assume the centering behavior has not changed recently? It appears the slur layout code is thinking the stems are on the sides of the notes as they are on standard staves, as opposed to centered as they are on tab staves.

Hmmm, I have not clearly understood what is not expected in the third measures: the overlapping you mention has not to do with tabs or linked staff, it happens even in a single standard staff. So, it looks likely it could be the matter of another issue.

About centring of slurs, I noticed it in the OP and I remember (rather vaguely, it is true) having fixed this quite a long time ago. I have no idea why (well, even if) it came (back?). Again this it probably the subject of a separate issue?

For the rest, the above example look right? Time for pushing the Pull Request?

I think maybe it was centering of ties that was fixed, but slurs are laid out somewhat differently?

I have no comments on the overall change as I really have great insight into what tab users expect.

@cadiz1, #19: well, I think I got it! The point is that, as Marc noted in #16, chords normally have just one slur.

In other words, in the screen shot in #19, the slur in the standard staff is not between C - D, but between C/E - D/F cumulatively (with slur below as the stems are up) and in the TAB staff the slur is not between E - F but between C/E - D/F cumulatively (with slur above as (potential) stems are down); so the two notations are equivalent.

At least, this is the general convention and MuseScore so far only follows this; to the point that, if I am not mistaken, it does not even has the notion of slurs attached to notes, but only to chords.

If writing for guitar has a specific, different, convention enough established (I have no experience on this, so you will have a more informed advice) requiring slurs specifically attached to notes, I think a specific feature request is needed.

What I would like to know is if you see any reason not to push the Pull Request fix as illustrated in #14.

Thanks!

@Marc, #18: yes, probably it was centring of ties.

PR pushed (waiting for Travis to say "Yes"): https://github.com/musescore/MuseScore/pull/2137

About slur centring: so, I did remember vaguely but perhaps correctly. Now it is just a matter of digging into a year worth of code to discover what has changed...!

Indeed, slurs are currently attached to chords as a whole and not notes, unless there is some guitar-specific exception I am not aware of. So only one slur per pair of chords would be the norm. Note that *nested* slurs are not uncommon, but these would generally go on the same side. So really, I think the default of placing multiple slurs on the same side and letting you sort it out from there if necessary is the right behavior.

As for why the slurs are on different sides of the staff between the standard and tab, that's easy - it's because the stems are on opposite sides. By default, slurs go on the side opposite the stems. On a standard staff, even with a single voice, stems are sometimes up, sometimes down depending on the staff lines of the notes. So slurs are sometimes above, sometimes below. On a tab staff, with one voice, stems are always below (by default) or above (if you set that option), so slurs should be always the opposite side from that. Meaning it will be normal and common to have a slur below the staff on a standard staff but above on tab.

I believe we all made a funny mistake in the above discussion, perhaps because of our familiarity with the standard notation.

In TAB staves with stem beside, slurs should never go 'stem-side' but always 'note head side'. I.e, not this:
NOT FOUND: 1

but this:
NOT FOUND: 2

With stems beside staves, the stems are outside of the 'music area proper' (so to speak) and nothing should go there which is not related to durations.

Am I correct?

If this is true, I plan to leave the PR quoted above as it is now, so that slur and tie directions at least are correct, and open a new issue regarding their vertical position.

Any comment?

"Simple" tabs (tabs without any stem) are, well, simple! And easy (more or less...).

"Full" tabs (with all the bells and whistles of standard notation, above all stems within the staff) are complex and not easy but, to a certain extent, rather predictable: if in doubt for a detail, look at standard notation, chances are a "full" tab doing the same thing would look correct.

If you need examples of "full" tabs, google for "Orquesta laudistica" and you'll find many (not always nicely engraved, but the idea is rather clear). The Orquesta laudistica is a kind of musical ensemble not rare in northern Spain and possibly somewhere in Latin America, which only uses plucked string instruments notated almost only in tablatures: small guitars, guitars, bandurria, laúd, guitarrón and so on... It is mainly to support them that I added the "full" tab concept.

In between, there are the "common" tabs (with stems but outside of the staff proper) which look like a no-man land: everybody does what he want, how he want, or maybe just as it comes out. It is difficult to set "rules" and then decide that something is "wrong", but perhaps general guide lines can be derived from the more frequent habits (so that "right" and "wrong" could at least be replaced by "more frequent (or expected)" and "less frequent (or expected)").

It is in this sense that I am proposing the change in #25. Do you think it would be the case to open a specific thread for discussing it? also considering that I am not going to change the already pushed PR only for this.

Thanks!

Fixed in branch master, commit f1a76e82a0

Fix #69846, #69821, #63561 - multi-voice TAB's: stem and slur positions

__Background__:

In the original TAB implementation, the "Stems above / below" setting was followed when there was only one voice, while with multiple voices, voice 1 stems were always above and voice 2 stems always below.

In issue https://musescore.org/en/node/63561 the OP reported that:
- with multiple voices, stems in TAB did not follow the "Stems above / below" setting;
- extra space was allocated for voice 2 stems.

Both issues were more apparent than real, because the example provided casually had no stems in voice 2 (all whole notes). With the commit https://github.com/musescore/MuseScore/commit/33797cd6c55490cd67a3267e5… :
- voice 1 stems are forced to be below or down according to the setting even for multi-voice cases and voice 2 stems on the opposite side;
- additional distance is allocated above the TAB staff (but not below) if stems are above or there are multiple voices or below (but not above) if stems are below and there is only voice 1.

__Issues__:

1a) The original stem directions were __by design__, assuming that with multiple voices notes of voice 1 tend to be above and notes of voice 2 tend to be below; then it is more sensible to put voice 1 stems above and voice 2 stems below, limiting the "Stems above / below" setting to the single voice case only.

1b) Stem direction controls slurs and tie placement and users are complaining that, with multiple voices, stems, slurs and ties are placed unexpectedly. See issue https://musescore.org/en/node/69846 and forum post https://musescore.org/en/node/69821 .

2) About additional staff distance allocation, with multiple voices it has to be allocated __both__ above and below, as stems may appear both above and below.

__Fix__:

1) This patch fixes 1) by restoring the original stem direction computation (single voice: follow "Stems above / below" setting | multiple voices: voice 1 unconditionally above and voice 2 below) when tab is configured to have stems beside the staff and also when it is configured to have __no stems at all_ (so that slurs and ties occur in expected positions).

2) It corrects additional staff distance allocation for the multiple voice case. No resources are spent to check the odd case when one voice casually has no stems over the entire system (in which case, additional distance on that side could in theory be spared).

Fixed in branch master, commit 9ca98d75c4

Merge pull request #2137 from mgavioli/Fix#69846_#69821_#63561_TAB_stems_slurs_in_multi-voice

Fix #69846, #69821, #63561 - multi-voice TAB's: stem and slur positions

Fixed in branch 2.0.3, commit 030b958af2

Fix #69846, #69821, #63561 - multi-voice TAB's: stem and slur positions

__Background__:

In the original TAB implementation, the "Stems above / below" setting was followed when there was only one voice, while with multiple voices, voice 1 stems were always above and voice 2 stems always below.

In issue https://musescore.org/en/node/63561 the OP reported that:
- with multiple voices, stems in TAB did not follow the "Stems above / below" setting;
- extra space was allocated for voice 2 stems.

Both issues were more apparent than real, because the example provided casually had no stems in voice 2 (all whole notes). With the commit https://github.com/musescore/MuseScore/commit/33797cd6c55490cd67a3267e5… :
- voice 1 stems are forced to be below or down according to the setting even for multi-voice cases and voice 2 stems on the opposite side;
- additional distance is allocated above the TAB staff (but not below) if stems are above or there are multiple voices or below (but not above) if stems are below and there is only voice 1.

__Issues__:

1a) The original stem directions were __by design__, assuming that with multiple voices notes of voice 1 tend to be above and notes of voice 2 tend to be below; then it is more sensible to put voice 1 stems above and voice 2 stems below, limiting the "Stems above / below" setting to the single voice case only.

1b) Stem direction controls slurs and tie placement and users are complaining that, with multiple voices, stems, slurs and ties are placed unexpectedly. See issue https://musescore.org/en/node/69846 and forum post https://musescore.org/en/node/69821 .

2) About additional staff distance allocation, with multiple voices it has to be allocated __both__ above and below, as stems may appear both above and below.

__Fix__:

1) This patch fixes 1) by restoring the original stem direction computation (single voice: follow "Stems above / below" setting | multiple voices: voice 1 unconditionally above and voice 2 below) when tab is configured to have stems beside the staff and also when it is configured to have __no stems at all_ (so that slurs and ties occur in expected positions).

2) It corrects additional staff distance allocation for the multiple voice case. No resources are spent to check the odd case when one voice casually has no stems over the entire system (in which case, additional distance on that side could in theory be spared).

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