Bad layout of articulations and slurs
Reported version
3.0
Priority
P1 - High
Type
Functional
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
In the attached score, the contents of measure 2 are exactly the same as measure 1, except that in measure 1 first the downbow was placed over the first note, and then tenutos were added, whereas in measure 2 (the problem measure) the tenutos were added and then the downbow. (It could be any articulation in place of the downbow.)
One way messes up the slur, the other doesn't.
Interesting to note: deleting the downbow in the first measure and then undoing the operation makes it the same as the second.
| Attachment | Size |
|---|---|
| bowing.mscz | 5.44 KB |
Comments
There are quite a few special cases in the articulation & slur layout code, designed to handle particular combinations of articulations in specific ways. And indeed, some of them depend on the order in which the articulations are added.
In this case, there is special handling for slurs and tenuto, but it only works if the tenuto is only articulation or, in the case of multiple articulations, if it is the second one. No idea what the assumption was behind that.
I also find it odd that an articulation on one side of a note affects spacing on the opposite side—it seems like it shouldn't.
Not sure what you mean by that. The downbow itself isn't affecting spacing of anything. It's the tenuto that is affecting the slur position, just as it should. It's just that this special casing fails in the specific case where there are two or more articulations and the tenuto doesn't happen to be the second one. It fails simply because the code basically says, "if there are two or more articulations, check the second one, and if it is a tenuto (or a staccato) on the same side as the slur, move the slur". Again, I'm not sure why the focus is on the second of them, but maybe at some point it might have been assumed articulations would be sorted in some particular way, and tenutos would always come out second in the cases that mattered.
Realistically, it probably doesn't make sense to do this at all unless the tenuto is the *only* articulation, or at least, the only articulation on the same side as the slur. Because otherwise we're moving the slur but not necessarily by a reaosnable amount ot clear the other articulation. It's really a complicated thing to get all cases right.
Ah, okay. Good to understand.
See also discussion at More systematic layout for articulations .
Issue still exists in 3.0 Beta, as do countless other examples of bad layout with articulations and slurs.
I guess technically the workaround is manually reshaping the slur...
All kinds of problems can be found by playing around, but this one is actually a regression: add a tenuto and a staccato on the same note (whether or not a slur end is also present), and they overlap. Tested in 3.0 Beta 2b25396.
![Screen Shot 2018-12-07 at 2.19.44 PM.png]( "Screen Shot 2018-12-07 at 2.19.44 PM.png")
Accents avoid slurs too much—possibly because the bounding box is rectangular instead of hugging the articulation's shape:
Slurs themselves are laid out badly, moving away from potential collisions without changing shape:
![Screen Shot 2018-12-07 at 2.24.26 PM.png]( "Screen Shot 2018-12-07 at 2.24.26 PM.png")
At this point it's better to submit new specific issues for the specific cases to fix.
I'm afraid I don't have time to do that. I can only say I'm surprised that testing didn't raise these issues before.
I would say it's not that no one noticed slurs weren't perfect, just that mostly people seem happy there are fewer collisions. Not so sure about the tenuto/staccato combination.
FWIW also, several articulation placement issues were pointed out and fixed over the past months. Overall things have come long ways.
I just added #279672: Staccato and tenuto overlap for the staccato/tenuto case. You say that's a regression, but it was actually bad in 2.3.2 too (maybe slightly better). Other combinations with staccato are not good either, again same as 2.3.2. But at least the pre-combined options are available.
As for other currently known issues, see also #279607: Articulation mark on first note of a group, or a solo beam is off. Stems pointing up., #83716: change articulation anchor for ["Fade In/Out", "Swell", "Wiggle Sawtooth/Vibrato"] from CHORD to TOP_STAFF, and #275590: Articulations are too close to tab numbers 2.X->3.0
For the record, my current slur PR https://github.com/musescore/MuseScore/pull/4374 does not deal with the case shown above in https://musescore.org/en/node/94546#comment-875988. Changing the shape of the slur after initial calculations is another matter. In principle, I see ways of getting better results at some computational expense. If the calculated autoplace adjustment exceeds some threshold we could try only applying it to the interior slur grips. Then perhaps re-run the calculation to see if we still need to raise it further, and so on. A task for another day.
The original issue here should be handled correctly by my code in https://github.com/musescore/MuseScore/pull/4411. The overlap between staccato and tenuto is already fixed, although it should be noted that the officially "preferred" solution is to use the built-in combined marking (which should also behave more reasonably for playback).
see https://github.com/musescore/MuseScore/pull/4411
Automatically closed -- issue fixed for 2 weeks with no activity.