Slurs and Ties: Autoplace minimum distance has no effect

• Dec 3, 2018 - 11:44
Reported version
3.0
Priority
P3 - Low
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4095, revision: 5859662

Open the attached score. Go to Format > Style > Slurs/Ties. Try adjusting the various properties and observe the effect on the score.

Result: "Autoplace min. distance" doesn't seem to have any effect.

Attachment Size
chansonette.mscz 25.13 KB

Comments

Priority P2 - Medium

Indeed, it looks like this setting is not used in the code. It was previously then was replaced by code that seems to use a hard-coded value of 0.5sp.

Status fixed open issues

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4421, revision: dc5e1d7

Open the example score again and adjust "Autoplace min. distance." It adjusts some slurs but most are left unchanged. No effect on ties either.

Status active needs info

The autoplace min distance only affects slurs that actually require autoplacing - ones that have collisions. No collision, no autoplace, so nothing for sluMinDistance to affect. Looking over your score, that seems applied consistently/correctly. Is there a specific slur where you feel it is not?

Status fixed open issues

Just double-checking one other issue. Adjusting Autoplace min. distance for this score only seems to affect the slur in measures 2 and 18; but it's not clear why it isn't having a corresponding effect on the slurs in measures 10-11 and 11-13 as well, since the latter are also placed above staccatto notes.

No autoplace was needed to avoid those staccatos - the curvature of the slur did that all itself. Easiest way to verify - disable autoplace for a given slur. If it doesn't move, then autoplace did not kick in. We do also have some code to avoid staccatos on the endpoints of a slur that kicks in before autoplace - this is code leftover from MuseScore 2. So we are able to do a "pretty good" job of slur layout even before autoplace kicks in.

The reason, btw, we are so conservative about applying autoplace to slurs is #280466: slurs too high, outside staff. It's a known limitation of the algorithm that once autoplace kicks in, there's a good chance it is going to go too far because we don't know how not to avoid the staff lines, also because autoplace doesn't have any effect on shape of slur, just position. So it's important the code get the best layout it can before autoplace.

That said, it's actually technically possible to tweak the algorithm to force autoplace to add the min distance in even if no collisions are detected. Pretty sure the results would be worse overall, though, because we'd be moving lots of slurs that are already placed very well and probably would not look better for it (end points would be moved further from the notes).

Priority P2 - Medium P3 - Low
Severity S3 - Major S4 - Minor

(leaving the issue open as much as a reminder of something to think about if/when we make overall improvements to how autoplace works with slurs)