Slurs do not move outside articulations if there is room to thread them through

According to Gould, the rule is, articulations go outside on the first & last note, inside for other notes (except staccato and tenuto which are always inside). Unfortunately, our algorithm won't make that distinction easy. Worth giving it a shot at some point, though.

As for the dragging behavior, remember, the algorithm goes in one direction only. There is a specific order in which things are laid out, and each goes on top of the other - no way to tuck later ones under earlier ones. So, since slurs get placed before articulation, you won't be able to drag the accent under a without disabling autoplace. Elsewhere it has been suggested that dragging could automatically do this, but there are other use cases where you don't want that. For example, if you want the accents above, you would hate to find that making a slight adjustment to the slur suddenly disabled autoplace and thus forced the accents back down.

To be clear: you can drag autoplaced elements around. It just won't work to change the vertical ordering. So that becomes an interesting feature request: disable autoplace automatically on drag only if an element is dragged above or below another. Still, I fear it wouldn't quite do what one wants, as disabling autoplace for that element may change the position of others as well.

Can anyone verify if this worked differently before the "skyline" code was merged a few months ago? In a build from August (20180 or earlier, what does you do get if you add accent marks to notes within a slur - under or over the slur? I'm guessing over the slur for accents on the endpoints, under the slur for interior notes. Or can someone point me to older builds for Windows?

The "skyline" code was implemented in the first half of September, here for articulations (September 12): https://github.com/musescore/MuseScore/commit/bb08200e1037edb5ec22c99b4…

After checking, I see no difference between before and after (at least with the examples below)

Some images:

1) Nigthly of September 1.
(the first image is the default behaviour: notes + slurs, then adding staccatos)

(The second image is the result after using Flip ('X') for the slurs, then enter staccatos)

2) Nightly of September 21. (so, same result)

(the first image is the default behaviour: notes + slurs, then adding staccatos.)

(The second image is the result after using Flip ('X') for the slurs, then enter staccatos.)

Thank you for checking! Some things changed more unexpectedly and I wasn't sure if this was one of them.

https://github.com/musescore/MuseScore/pull/4411

Sample image:

Fixed in branch master, commit 0dd864d372

fix #279880: place articulations under slurs except at endpoints

Fixed in branch master, commit 2679d8639b

Merge pull request #4411 from MarcSabatella/279880-articulations-under-slurs

fix #279880: place articulations under slurs except at endpoints

Just wanted to say, that this fix is marvellous! Look at the vtest I just created:

On the other hand, not sure if this was planed.

Look at the second C: if the slur exactly fits between staccato and accent or even below both (not shown), it will be there. Doesn't this conflict with Gould?

Please close again, if I am wrong.

Appended the score for the vtest.

Thanks for the kind words - I feel the same about your reordering of the main layout sequence :-)

It is a side effect of how slur layout works (checking for intersection with individual segments shapes rather than with the skyline) that you can get some cases where the slur will tuck itself into places you might not expect. The articulations get laid out first, then the slur checks for intersections, and lo and behold, there are none, so no adjustment is made.

In this particular case, this is arguably a good thing - why move the slur further away than is actually necessary? Especially given the poor results that would generally result given all we do is move the slur, not reshape it. Again, in this particular case, it wouldn't be so bad - the slur would now start and end just past outside the accents on the first and third notes, making us look more clever than we are (Gould does say it's fine to bring the accents in at the endpoints if they would otherwise be too far away). But remove the accents on those outer notes and we don't look so smart:

(that's the result of manually moving the slur up; you can imagine it would look nicer with accent marks still on the first & last notes of the slur)

Anyhow, Gould doesn't mention any such specific exception to allow interior accents to go outside the slur. So, technically, this could be considered a bug, albeit a much more minor one that we probably shouldn't try to address until we implement some sort of slur reshaping algorithm, since otherwise the cure will be worse than the disease. But also, note we provide a combined articulation on the palette and the official recommendation is to use those where possible. Then you can get the result in my image above for free :-)

So I'll leave this open but with the name changed since it really isn't about leaving articulations outside in cases where there is room inside, but more about not always creating room.

I was aware of the combined articulation, but didn't use it, as I wanted to stress the layout engine :-)

This said, I have to admit that I am not happy with these two possibilities to add an accent/staccato combination. Both ways should end up with the same result, i.e. the combined articulation should be (or should at least feel) only like a shortcut for the user. I will put this in a new issue.

I think there is general agreement it makes sense to automatically convert from separate to combined. I've suggested this be the job of autoplace, so disabling it gives you independent control again.