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

• Jul 28, 2020 - 12:24
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project

Version 3.5 R.C (Windows 10)

See animation below:
And test file (excerpt Tab and linked standard staff) : test hide.mscz

Video.gif


Comments

From what I see, it works as expected (and as version 2), especially for the TAB which is essential to keep the flags displayed in the right place (above or below the staff depending on the voices used, ie Voice 1 must not flip here, really bad effect: a beat seems missing above the staff) with this nightly, April 15: b30f199

On the other hand, it fails with this one, April 20: b2c71cd

I have no other intermediate nightlies (so I can't narrow down better), but two commits before, I see this one: https://github.com/musescore/MuseScore/commit/e9864d1e83db9b84e247b9545…
To fix: #294085: All elements set to normal position if all rests in voices other than voice 1 are deleted
Maybe a side effect of this commit?

Title Hiding notes or rests in a voice > 1 causes stems/beams to switch in a bad and unexpected way Hiding notes or rests in a voice > 1 causes stems/beams to flip in a bad and unexpected way
Reported version 3.4 3.x-dev

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.

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.

In reply to by Marc Sabatella

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.

Severity S3 - Major S2 - Critical

" case at hand for what appears to be a quite valid use case - invisible notes within a tied sequence"

That's right. To lighten the content of the tablature, without completely losing the information of the tied note.

In this case, there is a loss of information (since the last beat of voice 1 no longer appears above the staff as it should, so a beat is missing), and to make matters worse, false information is transmitted, since the last beat of voice 2 is now displayed as eighth notes (stems/beams voice 1 superimposed on the stem/quarter note of voice 2).

In summary, this commit, in this kind of use, completely breaks the behavior as it was designed as it should since the beginning of implementation of the TAB staffs, in their "Common" and "Full" staff type.
Under these conditions, I consider it deserves (loss/false informations) definitely a critical status.

In reply to by cadiz1

Workaround No Yes

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:

tab-stem-direction.png

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've been trying to read this discussion. It's so long, too many diverse and varied arguments, and having to go through translation becomes in this case a literally crippling handicap unfortunately. In short I get lost, and I gave up.

And your example (the attached picture) doesn't help me at all. This image is really confusing both in standard notation and in Tablature.

In standard notation, the C half note is supposed to belong to which voice exactly? It's really ambiguous here. The stem direction seems to indicate that it belongs to voice 2.
But how is voice 1 resolved? For me, this C should resolve both voices 1 & 2, with a shared note head.

And the same for the Tab staff. It's hardly less confusing. The C half note clearly appears as voice 1 here. But in voice 2, rests are missing, the first one, eighth rest, and probably also a half rest on the 3/4 beats, or probably better, a tied half note (possibly hidden if wished ) with the G quarter note.

So, I don't know how your PR is going to act. But I'm just as concerned now as before, because I don't know whether the previous behaviour (from the example shown on the Gif) will be restored or not.

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:

tab-stem-dir-2.png

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.

Attachment Size
tab-stem-dir-2.mscz 4.44 KB

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:

voice-stems.png

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.

In reply to by Marc Sabatella

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?

Workaround Yes No

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.

Status PR created fixed

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._

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.

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

I think that had been understood, but I should have edited the title earlier, sorry for that, so that you wouldn't have had to make this last clarification. In any case, thank you for restoring this specific behavior for TAB staves.

EDIT: it's fixed in branch 3.X.
I guess it's planned for the next 3.5 too ?

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.

Fix version
3.5.0