[TAB] Hiding notes or rests in a voice > 1 causes stems/beams to flip in a bad and unexpected way

I don't think that is a side effect, I think that was the intended purpose - to make the stem direction algorithm look at partial measures rather than being all or nothing for the entire measure. There was some discussion about whether this was actually a good thing or not, but the consensus was that it was. See for instance the discussion in the pull request starting with this comment from Dmitri:

https://github.com/musescore/MuseScore/pull/5371#issuecomment-554985130

To me it's still questionable whether it really is good to do this by default or not. But I will see if we can get Simon to weigh in.

Well, this is not intended actually. I think this is different from the thing you're talking about, which is about the second voice being non-existent at all for the crotchet period. Setting the note only to invisible (not deleting it and the rest generated too) shouldn't change the layout of the first voice.

-

BTW, why are you hiding the note here?

In the standard staff that makes no sense really because of the tie. But if you do hide notes or rests in one voicing, I would suggest that the new layout is more correct. Even so, it is unexpected and some people might for whatever reason be relying on the old behavior, so I do have some reservations about the change.

On the tab staff, I guess you are hiding it to achieve a particular look with respect to ties - you want to see the tie but not the note?

Maybe the answer is, we don't apply this particular change to tab staves. Or, maybe we limit to invisible rests, but still treat invisible notes as being present.

@Howard-C, your previous comments were posted at a time when no existing user found the change surprising or problematic, so it was possible to imagine this wouldn't happen. Also at the time no one had considered tablature, or considered the possibility of invisible notes rather than rests.

So comments posted previously are still relevant, but don't tell the whole story. We need to respond to the new information and decide if the original decision still makes sense in light of the current realities, or whether a compromise such as I suggest would be better.

Yeah, my Internet is bad and I rushed an answer, sorry about that. I now understood the issue and updated my first comment.

The code starting from this line is likely the reason, the main part wasn't really changed in that commit, so it's probably an unwanted side effect.

NP. The current code treats "holes" (deleted rests) and Invisibles rests the same, also tab and standard staves. I don't really have enough tab experience to say what is expected there with regard to rests.

BTW, my internet is going to be spotty today also.

No I was wrong... Setting other voices to invisible should bring voice 1 stuff back to normal, I just realized that's how we treat other cases involving invisible elements (by setting visible stuff normal). So yes, it is intended behaviour for standard staves. But for TAB staves, is a slur having only a visible start note correct notation (it means the note gets prolonged)? If so we'll have to rule this case out.

Probably we still want that code to function as it currently does with respect to the full measure - if all chords for voices >1 in that measure are invisible, we should treat it as not having voices. This is something I'm pretty sure lots of people rely on. But I guess we need to alter the behavior just in the case of partial measures. And now that I see how the code is structured, that might be tricky if not actually impossible. Maybe there is a solution but it isn't obvious.

But it should be easy enough to revert to the old behavior for tab - essentially ignoring stick and len and searching the whole measure. It's just still not clear if that's desirable or not.

No I don't think the point is about the entire or partial measure. We've discussed that and I still stand by the opinion that an entire measure has nothing to do with the directions and stuff at a certain tick, TAB or not. Maybe it's about how something can be allowed on TAB staves but isn't on standard staves which changes the meaning of notation.

The reason I bring up the entire measure is that I was proposing a compromise where we actually don't ignore invisible notes. In this proposed compromise, invisible notes in voice 2 would still cause hasVoices to return true. This doesn't affect your own personal use case at all - you'd never be using invisible notes. But it fixes the case at hand for what appears to be a quite valid use case - invisible notes within a tied sequence.

And the reason the full measure distinction comes up is, as I said, in the past hasVoices always returned false - and thus let stem directions be auto - if there were no visible notes anywhere in the measure. I said I was pretty sure people rely on it, actually I'm 100% positive, and I've done it many times myself. This would have to remain the case - a measure where all notes in voice 2 were invisible would need to still return false for hasVoices, so stem directions in voice 1 can be automatic.

So if we implemented the "invisible note still counts as a voice" compromise, it absolutely would need to make an exception for measures where *all * notes are invisible.

To me this could still be worth doing if possible.

Yes, we had a long discussion about this on the developer chat yesterday, and will be finding a way to make this case work. It's still not 100% clear to us what the best way to handle other cases is, but right now I am leaning toward, and planning to submit a PR for, simply reverting to the old behavior for tab in all cases.

The cases here was one we really hadn't considered, I think - hiding a note instead of a rest. But I think even for the case of rests, the rules for tab should probably be different than for standard staves. Consider, for example, the following:

Here there is a rest on beat 1 that is shown, but one on beat 3 that is hidden or deleted.

For the standard staves, it is desired (arguably) that the voice 1 note on beat 3 reverts to its default stem direction. That is, the note (C) is on the top half of the staff, so its stem should point down unless there is something in voice 2 to force it up. So the new algorithm in 3.5 does what at least some, and perhaps most, people would expect - what is shown here. 3.4.2 would have had that stem up by default, because it decides on the stem direction for the C based on whether there are multiple voices anywhere in the measure, whereas 3.5 checks only the relevant portion of the measure.

For tab, I do not believe this would makes sense. The default stem direction doesn't depend on the position of the note on the staff, and therefore I think it would be very surprising if we allowed that C on beat 3 to have a down stem. This would make it look like it was in voice 2 when it is not. So I think we need to continue to have that stem default to up, as I have it in this example. This is what 3.4.2 would have done, but 3.5 currently will put that step down. I think this much needs to be reverted for tab staves.

So, this is what the PR I plan to submit will do - by default, standard staves to be displayed as shown on the top staff here, and tab staves to be displayed as shown on the bottom. As always, the workaround is to simply press "X" to flip the direction.

I can't imagine that having the stem of the C down is the right thing to do in that example.
It looks a lot like voice 1 is not entered yet on that beat. (I mean in the standard staff, I have no opinion/experience on tab)

I apologize for any confusion,. There are indeed a lot of different cases to consider, and it can be hard to keep them all straight, and we struggled this ourselves in the chat yesterday.

The bottom line is, yes, for tab staves, my PR will revert back to 3.4.2 behavior. That means your example with the hidden note in voice 2 will continue to force the voice 1 stem up. It also means my example with the hidden rest will continue to do the same.

In my previous post I forgot to turn on the display of rests on the tab staff, which made it harder to understand. Here is that fixed to show rests:

So hopefully it is more clear now there really is a visible rest on beat 1 and an invisible one beat 3. And if you enter load this 3.4.2, I think you will find it produces this result, for the tab staff anyhow Why would someone use rests this way? Probably it's more common for standard notation than tab, but anyhow, let's just say there are situations where this happens, and I want to make sure we do what makes the most sense.

Also, I agree there is potential for confusion in the standard staff with my example, which is why I had reservations about the change made for 3.5 from the very beginning. But again, let's just accept for now there really are cases where this is what is expected. If it helps, one common example is music that is mostly a single voice (or two voices in unison) but splits into two separate parts only occasionally.

@frfancha for more on the rationale behind having the stem down in that case (which I agree isn't always desired), see https://musescore.org/en/node/294051, and the discussion in the original PR implementing the new behavior - https://github.com/musescore/MuseScore/pull/5371

And here is an example that to me provides a good example of when this makes sense in a standard staff - a case where it's really chords in one voice mostly, but splits into two voices just for a single beat. Here, you definitely don't want the stems to be all up in the second measure just because of the one beat that uses multiple voices:

This sort of thing come up quite often in both piano and choral writing, as well as the originally mentioned case of two wind parts in an orchestra score sharing a staff.

See https://github.com/musescore/MuseScore/pull/6391

Ok I certainly agree that in cases with only a few occasional 2 voice notes, keeping voice 1 stems "single voice" behaviour is the thing to do.
Certainly not in your first example but that can be manually overriden so we're fine.
I'm wondering if there is a logical criteria that could be added to the algorithm...
Could it be that what's shocking in your example is the fact that there is only one note single voiced?
Or is it more the fact that all the first notes of the measure are double voiced?

To me, it's really that I "should" have gone ahead and double that C half note in voice 2. Or left the rest visible if I wanted to explicitly show that the C was for voice 1 only. So it's a contrived situation, really, and frankly I don't care so much what the defaults are in corner cases like this because it is easy enough to flip the stem however you like. The "Jingle Bells" (!) case I posted later is a much more common one, much more important to get right, so even though I had reservations about the change for compatibility reasons, I do support it in general.

But also, I realize I was wrong about the workaround on tab staves - "X" doesn't function there, nor does the Inspector. So doubly important not to surprise people with unexpected defaults on tab. We had almost no complaints I recall about stem direction prior to 3.5 - not about the defaults, not about the inability to flip stems. This doesn't mean there wasn't room for improvement, but it does suggest to me that we are better off not changing anything abut stem direction on tab staves until someone gives a specific complaint about a specific situation. So that is what my PR does - restores behavior for tab to how it always worked before.

Fixed in branch 3.x, commit 4f2a0c94d9

_fix #308371: wrong stem directions on tab staves with multiple voices

Resolves: https://musescore.org/en/node/308371

For 3.5 we changes the hasVoices() algorithm,
used to determine default stem direction and other things,
to look at partial measures rather than full measures.
Overall, that's a good thing, but there are cases where it isn't.
While there will probably always be deabte on some corner cases
and there probably is no good algorithmic way of differentiating them,
one thing that seems clear is the rules for using voices on tab staves
is totally different, and this partial method does not work well.
You end up with notes having down stem
even though they are in voice 1 and there is also content in voice 2,
which just does not make sense in that context.
So this change simply checks for tab and makes sure
to look at the full measure in that case._

Fixed in branch 3.x, commit aabf881eaf

_Merge pull request #6391 from MarcSabatella/308371-tab-stems

fix #308371: wrong stem directions on tab staves with multiple voices_

To be clear: the fix here was to disable the improvement made in April, for tab staves only. So hiding notes or rests in standard staves will continue to work as 3.5 beta and RC do - notes in voice 1 will have default stems directions rather than being forced up, if there are no visible notes or rests in another voice that actually conflict. I do believe that change is for the better most of the time, and in the few where it is not, “X” flips it.

I won't pretend to understand exactly how the management of releases works, but yes, my assumption is this will be fixed for 3.5.

3.5.0 will surely be generated/branched off of the 3.x branch. And in the near futur I guess, as all known regressions seem to have been fixed meanwhile.

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