Bad slur shape on certain combination of notes

• Dec 10, 2018 - 14:52
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

I realize slur shape is pretty subjective, but the difference between the following two example seems like it has to be a bug, I can't imagine any reason for the second slur to be higher than the first:

slur-position.png

Just enter these notes yourself to see the same. Anything G or lower for the last note triggers the bug (as long as stem is down). Similar issues with similar shapes, Can't tell offhand what the issue really is about. I see this several places in my demo score "Reunion", which I've attached. First note being an eighth is one common element.

Attachment Size
Reunion.mscz 37.82 KB

Comments

• Dec 10, 2018 - 22:20

Cause of this has to do with the default position of the slur before the autoplacement (you can see this by disabling autoplacement). We allow slur starts to "float" along the stem according to advice in Gould, which actually gives us some pretty good defaults in a lot of cases before autoplacement kicks in. But then autoplace detects collisions that may or may not be valid and way overcompensates in some cases.

Here's another case, this time not due to a hook or "floating" along the stem. Slur on the left is without autoplace; on right is with:

slur-layout-2.png

I guess we're raising the slur enough to avoid the staff lines? We don't do that is the second note is just a step higher, not sure why we do here.

Anyhow, autoplace seems way too aggressive about avoiding collisions that don't really exist, and also by only solving by raising the overall height, you get situations where the endpoints are too far from the notes.

Luckily, disabling autoplace ends up doing reasonable things in most of these cases. I'd love to see improvement before release as this is a bit of a "black eye" on autoplacement, but

Reply

• Dec 11, 2018 - 17:35
Priority P1 - High ⇒ P0 - Critical

Answer to the case shown just above: we detect collision with ledger line, which doesn't happen if second note is a step higher. Once collision is detected, we resolve by raising all the way above staff line. That is the real problem. We could avoid the collision with the ledger line during initial (pre-autoplace) layout, but that won't help in cases like this:

slur-layout-1.png

Left is autoplace off, right is on. Way to big an adjustment for the small collision that exists.

Really, we need both changes mentioned here. If autoplace is on, we should avoid the ledger line in the initial layout to avoid creating a collision we know we'll move the slur to avoid later. But we also need to be less aggressive on the autoplace. Choosing the avoid the staff seems overkill, but I'm not sure there is an easy way to avoid that.

While none of these issues are necessary "critical" individually, collectively, I'd say there are enough problems with slur layout that we need to deal with at least some of it. I'm dedicating time today to fixing what I can.

Reply