fix #294085: all elements set to normal position if all rests in voices other than voice 1 are deleted

[mattmcclinch]

Resolves: https://musescore.org/node/294085.

This PR takes the place of #5303. It also makes #5366 unnecessary.

This factors out the inner workings of Measure::checkMultiVoices() into a variant of Measure::hasVoices() that takes a start tick and a length in addition to a staff index. This means that the long form of Measure::isOnlyDeletedRests() introduced in #5127 can be removed, since the new Measure::hasVoices() can be used instead.

Special thanks goes to @Howard-C for the work he did on #5303 and for catching the mistake in #5127.

[Harmoniker1]

So glad to see this :DDD
@anatoly-os, consider to put this in the 3.3.1 milestone (replacing #5303)?

[Harmoniker1]

Another small request: could you add me as a co-author?

[mattmcclinch]

Another small request: could you add me as a co-author?

Done.

[dmitrio95]

I would actually not put it into a patch release since it would probably alter an appearance of existing scores, and it does not look like correcting some obviously erroneous layout.

Concerning the change itself, I would like to ask @MarcSabatella or anyone else interested for a review: this change will give better results in the original case but I am not sure whether in the following (maybe somewhat artificial) example the second layout is clearly better and more correct than the first one, while this is exactly what this change will lead to:

Also, whichever decision we make, it would be good to add a vtest (or just a plain mtest test case) for this to be able to track behavior of the layout algorithm in such situations.

[Harmoniker1]

If you intend to have that, then the rests in voice 2 shouldn't be deleted.

Deleting rests in other voices itself is pretty uncommon generally, but it's very common in orchestral music, like the example I gave in the original post. Don't know if you noticed, but in my example, that chord is played by two instruments. They have the same note at the start, but have different ones later. Since both instruments already have their notes, the rests in voice 2 are not meaningful anymore, so they should be removed. You can see this layout in parts which are each shared by two or more instruments of the same kind (like Flute 1 & 2). But in other cases, for example on a piano score, those rests of voices 2, 3 and 4 automatically generated shouldn't be deleted by all means, because they represent the tacent interval of these voices, they're still meaningful, and this fix doesn't affect this case.

I have to say, I haven't encountered many things in MuseScore that annoy me, but this one is no.1. No matter from what prospective do you look at this issue, the design should always be like this. The barlines are for rhythm and other uses, the layout concerning relations between voices should not be affected by them. I think Matt's proposal here is perfect, that hasVoices() should be about start tick and end tick, not about a whole measure.

[Jojo-Schmitz]

I agree with @dmitrio95 here on move that out to 3.4, due to the potential inadvertant and surprising layout changes

[Harmoniker1]

I agree with @dmitrio95 here on move that out to 3.4, due to the potential inadvertant and surprising layout changes

If we are talking about this, then I agree too. As long as it is in a plan, whichever plan ;-)

[Harmoniker1]

@dmitrio95 Is this PR going into 3.4?

[anatoly-os]

Discussed the expected results of the layout with three pianists. Three of them said that they don't care whether the beams are placed up or down. Two of them said that beams should be up if the notes are written for the vocal part since distinguishing voices is easier with the beams direction aligned.

To sum up, I would vote for not changing current behaviour since there are no rules defining the correct layout.

PS A question to the author of the initial report: "For which instrument do you want to write that notation?" I cannot imagine any instrument that could play the notation. (Probably @Howard-C?)

[MarcSabatella]

Sorry I missed being tagged earlier.

I have mixed feelings. As I understand it, the original issue that this relates to was already fixed (https://musescore.org/en/node/284481). It had to do with a case where the same exact measure might be displayed two different ways depending on the order you did things. The sort of non-deterministic behavior was clearly wrong and I'm glad it was fixed.

This behavior here is a change that doesn't really address any inconsistency that I can see, it alters the default layout in a particular situation. The default was correct in some cases, incorrect in others. Now it will simply reverse those.

Either way, users have the ability to flip the stems manually. The concern is whether users who preferred the old behavior and thus didn't bother to manually lock in their stems would now be unpleasantly surprised by the change in the default for their existing scores. I imagine there will be such cases indeed. So I do understand the hesitation.

The use cases for which this is the desired stem direction is probably the minority. That is, given the two choices shown in #5371 (comment), I believe the second is desired more often than the first. Still, I continue to advocate people don't delete rests but simply hide them, and this change from what I can tell won't affect that case at all.

Maybe I'm missing something, but this seems like a corner case that is easily solved by pressing X when needed. I'm having trouble understanding how this minor extra click could be seen as annoying enough to be worth risking a very real change in existing scores, unless we truly believe it's like 100:1 in favor of the situations where the new layout is preferred.

[MarcSabatella]

On the other hand, the big downside of manual flipping of stems is that it doesn't do the right thing when transposing. So getting the default right where possible is definitely good.

So all in all, put me down as "in favor of the change, I guess" - seems like a bit of a risk for a pretty small win, but probably worth it.

[Harmoniker1]

PS A question to the author of the initial report: "For which instrument do you want to write that notation?" I cannot imagine any instrument that could play the notation. (Probably @Howard-C?)

@anatoly-os Maybe you missed something I said in previous comments. In the original picture I posted in https://musescore.org/en/node/294051, the staff is shared by two flutes, one using voice 1 and the other using voice 2, but only when the rhythms are different. If the notes can be written as chords, they're notated as chords (in voice 1). There will still be voice 2 rests auto-generated below the chords, but those rests are meaningless, and keeping them is wrong. If a tick still has voice 2 rest, stems in voice 1 are always up; if it doesn't, then the stems have normal layout, since there's no point in keeping them all up. This is the basics of orchestral notation. So this answers your question "for what instrument do you want to write that notation": this notation is for multiple instruments in one shared staff.

Piano, however, is totally different. It's played by one player, no matter how many voices are written. I'm also a pianist, and if you ask me the same question, my answer would also be "beams should be up", but this also requires the voice 2 rests not being deleted. Unlike a staff shared by multiple instruments, normally if a tick has 2 voices, then the entire measure it's in has 2 voices. It's best to keep the rests untouched, but if you don't want them, you can turn them to invisible and you still have the stems all up. But if you delete them, this is a totally different thing. It probably suggests you're starting a new musical sentence or paragraph from the middle of a measure. In this case, I don't think the stems and all others in the new sentence or paragraph should be affected by the voice count in the previous sentence or paragraph.

So, to sum up, I still believe not matter in what way do you look at this issue, it definitely needs fixing.

[Harmoniker1]

Maybe I'm missing something, but this seems like a corner case that is easily solved by pressing X when needed. I'm having trouble understanding how this minor extra click could be seen as annoying enough to be worth risking a very real change in existing scores, unless we truly believe it's like 100:1 in favor of the situations where the new layout is preferred.

I believe 100:1 is not an underestimation, given that all our discussion is based on the rests being actually deleted, not hidden or accidentally ignored. And yes, it can be real annoying, especially when you discover yourself having incorrectly placed stems, accidentals, slurs, ties all of a sudden.

[Harmoniker1]

Bottom line, I tried Sibelius just now and, believe it or not, it does just what I suggested. No offense.

[MarcSabatella]

I didn't miss your comment, I'm just wasn't understanding why having to press "X" in that situation is such a problem, given that the "correct' stem direction is ambiguous anyhow. In many if not most such cases, what people really do is show the entire measure using two voices to be clear, only returning to chord notation in the next measure. And again, it's really recommended to hide rests rather than delete them anyhow, so setting the stem direction manually is to be expected I think.

So really, the only issue I see is the transposition one, which I didn't see right away. That's the only respect in which I see this as anything but expected behavior to need to press "X" every once in a while. But the transposition issue is real, so it's probably worth the also very real likelihood that we are going to mess up some existing scores by this change.

[Harmoniker1]

given that the "correct' stem direction is ambiguous anyhow.

OK, I'm gonna get real straightforward here. It is not ambiguous at all. In fact the rules are very simple: if you do want to see the current stem positions, don't delete voice 2 rests. If you delete them, the only thing it can mean is that the tick doesn't contain more than one voice anymore, which means layout should of course be restored.

[MarcSabatella]

I don't mean that MuseScore's rules are ambiguous, I mean the actual rules of music notation are. Sometimes one stem direction is desired, sometimes the other is - it depends on the musical context and the reason for one voice disappearing mid-measure.

To me it's not obvious that people should necessarily know that you can trick MuseScore into doing what you want by deleting versus hiding or vice versa. I don't see why the user should expect these to have different results, actually, except in hindsight after being told. I don't really like any behavior that relies on deleting rests, as I don't like advising people to use that feature.

Anyhow, to me, it remains the case that if you care which direction, you set it manually, same as you would in a hundred other situations where the default might not happen to be what you want. It's only trhe transposition consideration that moves me into the camp of agreeing there needs to be a way to get auto stem direction to work this way.

[Harmoniker1]

I'm going to let that go, and it's only because you also agree to this change, although for a different reason.

Bottom line: I'm forever grateful that MuseScore has a way of deleting voice 2/3/4 rests. You may not like any behaviour that relies on deleting rests, but the fact is, you cannot avoid it in orchestral music.

[mattmcclinch]

I believe that in most cases invisible rests do not affect the layout of other elements. And I thought (though I cannot verify at the moment) that currently, and with this change, the layout will be the same whether the rests are deleted or made invisible.

[MarcSabatella]

Invisible rests do affect layout with respect to width, and I believe people rely on this to get effects like strict proportional spacing (filling measures with empty sixeenth rests. But currently, we do still treat the measure as not multivoice if voice 2 is literally all invisible rests.

So, again, I'm actually fine with the general idea that a deleted or invisible rest would not prevent voice 1 from having auto stem direction during that range. I wish it had been this way to begin with. Because it wasn't, I have a slight concern over breaking a score of someone who depends on it, but it's probably rare to rely on this, and easy enough to fix by pressing "X". So again, I don't oppose the change. And I think it's just as well that the behavior is the same regardless of whether the rest is hidden or deleted.

But looking forward, I still there were a way to allow voice 1 stems to still do the normal auto-direction thing in other cases where realistically I'm just not so sure we can predict. In particular, I see it with rhythmic slash notation - would be great to have a way to get auto stem direction in voice 1 (the full size notes) here:

I suppose we could check for cases where voice 2 or 4 are empty, and treat 1 using default rules if so. But having a new value for direction that says "really auto, multivoice or not" would give the user more control over this still. Something I'd still like to see at some point - that or some other more general solution.

[Harmoniker1]

@mattmcclinch Needs rebasing

[AntonioBL]

I don't know why, but this PR messes with slur positions in the second staff of vtest tie-2.
Some slurs seem better than the original one, but some are worse, e.g. those in measure 5 (overlapping notes and slurs).
Original:

With this PR:

Diff:

[mattmcclinch]

I fixed the problem with the ties, and now it passes the vtests.

[shoogle]

I'm in favour of this change in general, but there are cases where it is sub-optimum. To use the example above:

what this change will lead to:

Here I would say that it is better to keep the stem direction consistent than to flip. The only reason to flip would be if it produced some advantage in terms of saving space on the page, but in this case:

1. The up beam extends no further above the staff than the previous content in the measure.
2. The down beam extends just as far below the staff as the up beam did above it.

So there is no advantage to flipping the beam. The other beams in the measure are upward, so it makes sense for these to be as well. Of course the algorithm to achieve that would be rather more complicated than just looking at rests in other voices.

[Harmoniker1]

so it makes sense for these to be as well.

I think otherwise. There's literally nothing (not even hidden rests) in voice 2 for the last four notes, flipping the beam is musically meaningless. Maybe the first picture looks prettier than the second in this case, but what about the case in which the second half of the measure has a completely different melody than the first half? Now it really makes sense for the stems and beams not to be flipped, since these two parts are irrelevant.

[MarcSabatella]

To me looking at the skyline over complicated it and also misses the point, it’s more about what is a logical and correct use of voices. And at this point I’m really just concerned with compatibility.

[shoogle]

@Howard-C

flipping the beam is musically meaningless [in this situation]

Which is why we are allowed to default to the prettier option.

what about the case in which the second half of the measure has a completely different melody than the first half?

If the melody contains beams then my rules still apply. If it doesn't then the question is irrelevant.

@MarcSabatella

it’s more about what is a logical and correct use of voices

In this situation there is nothing in the other voices, so there is no correct way to use them.

To me looking at the skyline over complicated

That's fair enough. I raise this as an example of what we could do rather than something that we will do. I want to know where we draw the line between what is reasonable and what is not.

In your case, I take it that "reasonable" means "the simplest algorithm that produces a result that is technically correct and does not take up excessive space". You would favour such an algorithm over one that is more complicated, even if the complicated algorithm produces a result that is equally correct but looks prettier or takes up less room.

[MarcSabatella]

As a general statement, I can buy into "the simplest algorithm that produces a result that is technically correct and does not take up excessive space". But to me the question of what is technically correct or equally is not always so simple, and "looks prettier" is subjective. So rather than worry about generalities, I'd rather talk specifics here. To me it would be quite surprising, and thus less correct in that sense, to see stems up for the B & C in the given example (assuming treble clef) but stems down if it were C and D, or D and E. Either the rule is that stems go back to their usual behavior when there is no content in that partial measure, or the rule is we force voice 1 stems up if there is any content in voice 2 anywhere. It's not about simplicity of implementation but about user expectation based on standard practice. Unless we can collect enough examples of this to establish there really is a rule that says to favor up stems in some quantifiable set of circumstances regarding consistency or whatever but revert to down stems in other cases, I think any such determination should be up to the user, and the default should be simple, predictable, and "correct" as often as possible.