[Regression] Bad layout of slurs in presence of cross-staff beams

• May 22, 2019 - 02:53
Reported version
3.x-dev
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

Cross-staff notation was a mess in 3.0 to be sure, but there a few we got right that now we don't. Not so much because something broke, but because some of what goes on in layout with cross-staff notation involves making educated guesses about stem direction in the early stages of layout then trying to correct these guess later, and sometimes it's really just too late. So we get right or wrong results based on whether our initial guess happened to be right or not. And it was some of the initial guess code that I changed for 3.1, here:

https://github.com/musescore/MuseScore/pull/4814/commits/e0bd254d48137f…

That's code that has gone back and forth many times over the years, dating back to before 2.0. We can keep tweaking it to guess right in more cases, but there is no getting around the fact that it's still just a guess, and things will go wrong if the guess was wrong.

The two cases reported have to do with slurs and with beams. The symptoms differ, but the underlying cause is the same - wrong initial guess coming back to haunt us.

For the bad slur case, I have a fix where I simply choose to ignore the stem direction for slurs starting or ending on cross-staff beams. It's not ideal but it's way better than relying on a wrong guess. The slur is not even necessarily cross-staff - it might just connect notes that happen to be on cross-staff beams. So I can't really fix it by putting it off until even later.

For the bad beam case, it's a beam in one voice that gets messed up because of a bad guess about a beam in another voice (!). That's because stem direction affects the layout of overlapping notes, and if we have wrong stem direction in mind, we'll have wrong layout of overlapping notes too. Not sure the best fix for this.

My plan is to have some sort of PR to at least improve the situation before the end of (my) day, and to add more details here to show specific cases fixed, and is there are cases not fixed, I'll describe those too. But see https://musescore.org/en/node/289441 and https://musescore.org/en/node/289471 for the original reports.

Comments

• May 22, 2019 - 04:58
Title [Regression] Bad layout of slurs and other beams in presence of cross-staff beams ⇒ [Regression] Bad layout of slurs in presence of cross-staff beams

I am submitting the beam issue separately, since I do indeed have two separate fixes.

For the slur issue, consider the following, which is the current 3.1 default:

slur-cross-staff-beam-1.png

Although one could argue with the choice of default direction for the slur, the layout looks OK for that choice of direction. But here's what happens if you flip it:

slur-cross-staff-beam-2.png

The slur is hanging in mid-air on the left because we erroneously think there is a stem there. This is the bug as originally reported, reduced to a simple case.

In 3.0.5, the default layout made the better choice for slur direction, and there is no slur hanging in mid-air:

slur-cross-staff-beam-3.png

Flipping it yields something that is technically OK but doesn't look good - there is no good reason to lay out the start of the slur to the stem in this case:

slur-cross-staff-beam-4.png

The fix I will be submitting combines the best of these. The default layout is like the nice version with the above direction from 3.0.5, and the flipped version is like the default version in the current master. The small price is there will be times we lay out close to the note when we maybe should have laid out to the stem, but it beats laying out to a stem that isn't there. Only slurs involving notes on cross-staff beams will be affected.

Reply

Fix version
3.1.0