This isn't a duplicate. The links relate to collisions between slurs and slurs, and between slurs and triplet numbers. See attached score for examples.
True, although most likely it's the same underlying cause. As I recall from having looked at this, it would not be an easy fix, these things are handled a bit specially by autoplace.
I think the trigger here is fingerings on beamed notes, as this order in which things are laid out does not easily permit. I'm sure it's solvable with effort.
Turns out the specific issue of fingering on beamed notes is easy enough to fix. Only for notes "inside" slurs - the endpoints are handled very differently in order to not create bad effects with accidentals or other markings. We do a lot of complicate special-casing to deal with articulations on the endpoints. Similar processing would I guess be needed for fingering, but it would be more complicated because fingering is placed per note rather than per chord, fingering placement rules are themselves more complicated. So the "easy" fix in the following PR applies only to the notes inside the slur, but it should be an improvement anyhow, if not a complete resolution:
Instead of a new topic, here is an included collision in 3.2.3 and Nightly
:
Voice-1 with stems flipped down (to make room for cross-staffed notes above, not sure if this is the reason or not) the shown fingering collides with the under-slur with no auto-correction, and also there is collision at top right:
Right now slurs completely ignore elements on the start and end elements. That's to avoid things like this the acrobatics to avoid accidentals discussed in https://musescore.org/en/node/279737#comment-877294. Fingering would potentially create similar weirdness but avoiding fingering for notes within the slur is more viable, as per my PR
Ok.
Also, beware of the collision found in nightly (and 3.2) of the fingering upon a flag when using two voices. For example (forgo the bogus finger numbers :)
Second-voiced flags almost always collide with the finger-number.
Ooh, that's not good, an unrelated bug you should file separately. Right now we apply a fixed offset to the fingerings in that situation but it's obviousy not a good one if there is a hook.
Comments
We need a score (or extract) to show what you are saying (about multiple slurs/fingering numbers) and by specifying where and how.
Here's some pictures and the score file
Thank you
See #279948: Nested slurs collide
#280221: MuseScore Beta3 triplet and fingering collide without any help of autoplacement.
This isn't a duplicate. The links relate to collisions between slurs and slurs, and between slurs and triplet numbers. See attached score for examples.
True, although most likely it's the same underlying cause. As I recall from having looked at this, it would not be an easy fix, these things are handled a bit specially by autoplace.
I think the trigger here is fingerings on beamed notes, as this order in which things are laid out does not easily permit. I'm sure it's solvable with effort.
For whatever it's worth, I'd love to see this one fixed.
Turns out the specific issue of fingering on beamed notes is easy enough to fix. Only for notes "inside" slurs - the endpoints are handled very differently in order to not create bad effects with accidentals or other markings. We do a lot of complicate special-casing to deal with articulations on the endpoints. Similar processing would I guess be needed for fingering, but it would be more complicated because fingering is placed per note rather than per chord, fingering placement rules are themselves more complicated. So the "easy" fix in the following PR applies only to the notes inside the slur, but it should be an improvement anyhow, if not a complete resolution:
https://github.com/musescore/MuseScore/pull/5104
In reply to Turns out the specific issue… by Marc Sabatella
Marc, I just gave your code change a try and it does eliminate some collisions. Thank you for that! I appreciate it.
I've attached screen captures, before and after, in case they might be of interest. (I'm a MuseScore newbie so please excuse any beginner crimes.)
I would agree with the comment on your PR that "placing the slur outside the fingerings... is less desirable."
In reply to Marc, I just gave your code… by emillan
Instead of a new topic, here is an included collision in 3.2.3 and Nightly
![finger_slur_collide1.png]( "finger_slur_collide1.png")
:
Voice-1 with stems flipped down (to make room for cross-staffed notes above, not sure if this is the reason or not) the shown fingering collides with the under-slur with no auto-correction, and also there is collision at top right:
Right now slurs completely ignore elements on the start and end elements. That's to avoid things like this the acrobatics to avoid accidentals discussed in https://musescore.org/en/node/279737#comment-877294. Fingering would potentially create similar weirdness but avoiding fingering for notes within the slur is more viable, as per my PR
In reply to Right now slurs completely… by Marc Sabatella
Ok.
Also, beware of the collision found in nightly (and 3.2) of the fingering upon a flag when using two voices. For example (forgo the bogus finger numbers :)
Second-voiced flags almost always collide with the finger-number.
Ooh, that's not good, an unrelated bug you should file separately. Right now we apply a fixed offset to the fingerings in that situation but it's obviousy not a good one if there is a hook.
In reply to Ooh, that's not good, an… by Marc Sabatella
Ok, got it: #296276: Fingering collides with note flags, accidentals, note stems etc.
Came up again at https://musescore.org/en/node/331308.