Voice inversion with unisons in standard/tab staves

That chord would be impossible to play with any normal hand anyway.

Normally one would allow the voice 2 A to ring and it should be indicated by an endless slur in the tab attached to the open string.

Maybe I am misunderstanding something (the expected result does not look different from actual?), but I do not think I would consider the actual behavior here to be a bug. There are two different notes that need to be played here. Both happen to have the same pitch, but if you didn't *mean* two different notes, why *write* two different notes? The algorithm figuring out the tab is trying to give you what it thinks you want - two different notes that happen to have the same pitch. You can't do that with only one string, so it uses two. Seems to be doing exactly what you asked. If you really wanted only one "A", you shouldn't have written two, but instead used a rest in voice 1. Then it would have worked as you expected. As it is, though, if you write two notes in the standard staff as you did,. there are going to have to be two notes in the tab staff as well.

@Cadiz... I see why you are concerned about the voicing of the A note in the tablature - you want an easier way to make all the fifth fret A notes invisible.

Also, after reading ChurchOrganist's comment about guitar notation vs. conventional engraving rules, I revisited some of Carcassi's guitar pieces and they are rife with notation like this (similar to yours):
NOT FOUND: 1

Apparently it is the very nature of stringed instruments' ability to play the same note at different fingerboard locations which give rise to this situation where MuseScore actually shows the two enharmonic tones in the tablature - with the resultant 'impossible' fingerings.

Of course, as Marc mentioned, a rest can be used in voice 1 - although this would eliminate the double stem.

Also, I tried ChurchOrganist's suggestion to use the tab staff for note entry of the crotchet A, but the 5 key enters a '5' in the tablature, not a crotchet.

You'll probably have to keep using 'invisible' for the time being to hide those enharmonic notes.

Regards.

It seems to me we have to clearly distinguish between two areas:

1) Differences between 'standard' and tab notation (leading, among other, to the "impossible tabs")
2) Fretting algorithm

1) Difference between notations

Let's take Jm6stringer example above: to me the TAB is a rather accurate rendition of the contents of the standard staff. The fact that the resulting fretting is beyond the possibilities of a standard human hand is a rather clear indication that the original standard notation as written is beyond human possibilities.

As ChurchOrganist pointed out, this is because the standard notation in the top staff is not to be taken 'literally' (as a pianist would execute it, for instance), but follows different conventions, a specific 'guitar dialect', so to speak.

I don't think MuseScore could be expected to know all the different 'notation dialects' for all the instruments. If the required contents of the standard staff is different from the required contents of the TAB staff, there is no alternative to use two not linked staves and fill each one as needed.

I think this area could be tagged as "Won't fix" because 'fixing' it (assuming it is possible) would raise more problems than it would solve.

2) Fretting algorithm

This is a more complex area. Keep in mind that the algorithm, which assigns string and fret to a note which does not have them yet, should accommodate a variety of situations: entering a chord from top to bottom note, entering a chord from bottom to top note, possibly split across several voices, and so on.

Each time a note is added, deleted or changed in pitch, the algorithm evaluates all the notes, across all voices, and attempts to assign string and fret to each. It does some assumptions; for instance, it assumes that, if a note already has fretting, it should be kept, unless it conflicts with another note (no two notes on the same string) or it leaves some notes without a legal fretting; in which case, it starts over afresh.

The bottleneck is: when some notes have fretting (previously entered notes) and some do not, how (better, when) to consider the notes without? Before, after, drawing straws?

The current implementation evaluates not-yet-fretted notes rather early, as this seemed to work better while fretting chords both entered from top to bottom and from bottom to top. This explains why, in the OP initial example, the last entered note (the A crochets) seem to 'steal' the 5th string from the A semiquavers: the former (being not fretted yet) is evaluated earlier and 'reserve' the string most suitable to itself (the 5th); the latter come later and have to be content with the remaining 6th string.

It can be improved, of course, but correcting the specific aspect described in this thread (which I would label as 'advanced') should not interfere with the basic working.

In no case, the algorithm can be expected to take into account more than the current chord or to be able to 'plan ahead' the appropriate fretting for a whole passage.

So, unless there are other, more basic, bugs, my first reaction for this second area is "Postponed". With the following workarounds:

*) If the automatic fretting is unsuitable / unexpected, try entering the TAB first: there you can decide the fretting yourself in each detail.

*) If this leads to unidiomatic standard notation, then the two notation are not compatible (area 1) above) and a general purpose notation programme like MuseScore cannot be expected to 'translate' one into the other: use non-linked staves and fill each with the specific details of each convention.

Thanks,

Maurizio