Slurs collide with grace notes
Reported version
3.3
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
Win 10 / MS 3.3.4.
See attached score example.
See also:
#283283: Collisions between slurs and fingerings
#280312: Slurs collide with tuplet numbers and brackets
#15891: Slurs collide with ties
#279948: Nested slurs collide.
Attachment | Size |
---|---|
slurs_collide_grace_notes.mscz | 5.62 KB |
Comments
Related to #310776: [EPIC] Grace note issues
Just noticed this too, definitely an issue.
See https://imslp.org/wiki/File:Btsn31_3.pdf (4th system) for an example of slurs nicely drawn around grace notes.
BTW this is what lilypond produces, basically just shifting the slur higher (without changing the shape) http://lilybin.com/pylmku/4, however lilypond seems to use a shorter default stem height for the grace notes too (in all cases, not just when slurred).
The slur layout code is in need of a major rewrite. The collision avoidance as implemented for slurs is a hack that was kind of retrofitted onto the general autoplace system. It would be possible to hack it further to deal with grace notes, but probably better to start from scratch on this. I know Simon (@oktophonie) was supposedly working on some specs for this, not sure of the status.
In reply to The slur layout code is in… by Marc Sabatella
Haven't looked at that code yet but it does generally seem to produce reasonable results...
I would say that the basic layout of creating the initial shape is fine. I haven't really followed the math of it, but it's a standard bezier curve connecting two end points. It's what happens after that to avoid collisions that things get hairy. First, most collision avoidance in MuseScore is done by comparing shapes checking the current element shape against that of the skyline as constructed thus far - and if they overlap, moving the current element further from the staff. For slurs, we don't compare to the skyline directly, but instead loop through segments. There was a simple reason for that but it escapes me. Either way, the algorithm created cases where we moved the slur kind of crazy far from the staff to avoid some note in the middle of the staff, resulting in endpoints too far from the notes they are attached to. So then we added code to try increasing the curvature of the slur as necessary to bring the endpoints in closer. Sometimes that produces good results, other times no so much, and it creates glitches as you try to edit and the default curvature changes out from under you.
One thing you'll find if you do try modifying the existing code to avoid grace notes is situations similar to those involving accidentals as you see in #274208: Slur too high with accidental and #292529: Autoplace: slurs intersect accidentals. There is a lot of finesse to doing this well, and it's something that I know top-notch engravers say they spend inordinate amounts of time tweaking in Finale or Sibelius as well. So I don't feel too bad about what we manage overall, but still, the devil is the details of those corner cases.