Dipsy-doodle slurs -- bizarre shape and position due to autoplacement
Take a look at the attachment.
1. Measures 1 and 3: recumbent slurs, with end pointing in back toward the beginning
2. Measures 3-5: slurs are way too curved.
3. Measures 6-9: bizarre curvature and placement of slurs
Measures 10 to the end have autoplacement disabled. Slurs in these measures are rendered the same as in version 2. Thus, the failure is due to autoplacement.
Version 3.4.2, revision 148e43f, 64-bit AppImage.
| Attachment | Size |
|---|---|
| Formatting Test.mscz | 9.69 KB |
Comments
In general, the autoplace algorithm strives to avoid collisions and produces very good results, but there are indeed a handful of corner cases where results can be better if you disable it and allow the collisions to take place and then move or reshape the slur manually.
Indeed.
I forgot to point out that the problem in Measure 1 is not caused by autoplacement. It's an old bug.
In reply to Indeed. I forgot to point… by RexC
“Bug” is a strong word for these. The algorithm works as designed, and as mentioned it produces good results in mkst cases. But these are all special cases that would need special handling to produce different results. Not saying such design improvements won’t happen so e day, but for now, these are just some of the cases where manual adjustment is to be expected.
In reply to “Bug” is a strong word for… by Marc Sabatella
For what it's worth, I find that this sort of thing happens frequently, even within a short score. Nicer slurs and better placement are high on my wish list of changes. The good news is that I rarely or never encounter any other problems.
In reply to For what it's worth, I find… by RexC
You get better results in your example by disabling autoplacement for the mordent, trill, accent and turn rather than for the slurs. The others look liveable with to me even with autoplacement enabled,
![Formatting_Test.png]()
In reply to You get better results in… by SteveBlower
Yes, thank you. I note that it doesn't work well for the accent mark, but otherwise it is an improvement. That might be a clue as to how to fix this.
I frequently encounter those overly curved slurs, and I never leave them like that. For what it's worth, the attachment shows what Frescobaldi/Lilypond did with it. It's still not perfect, but it shows what I think slurs should look like.
In reply to Yes, thank you. I note that… by RexC
Yes that is nicer but your example would also look nicer with less loopiness for the slurs if there were fewer measures per system as in the Lillypond example.
In reply to Yes that is nicer but your… by SteveBlower
Thanks for your reply. You're right. The Lilypond score is spaced better, and stretching the line a little does improve some of the slurs. But this exposes other problems.
The lines are a little crowded horizontally in comparison with version 2, and expanded vertically in comparison with Lilypond.
* I think it would be better if the defaults were modified.
* The slurs still need to be fixed, in my opinion.
The MS 3 spacing defaults seem way off. I have attached a heavily revised score.
* The default measure spacing is 1.2, and that seems too tight. I had to increase it to around 2.0 to approximate the appearance of version 2, and it should be even more to approximate Lilypond output.
And there are other problems.
* The minimum staff distance style setting does not have any effect on this file. (Why not?)
Adjusting the maximum staff distance works in this case, but I don't think that is the right thing to do, as it could lead to crowding of notes. MS 3 doesn't seem to handle this very well. Am I missing something here?
Misshapen slurs in measures 19 and 22
Collision in measure 26
In reply to Thanks for your reply. You… by RexC
As I said before, yes, eventually it would be good to add more special cases for these particular situations. As it is, the algorithm is mostly one-size-fits-all with only a little special casing. BTW< there is an actual bug here too, slurs that adjust to avoid ornaments don't settle back if the ornament is manually moved, you have to disable autoplace on the ornament to get that to work. But at least it does work to do that.
When you say you feel the "lines" are crowded or expanded, I am not sure what you mean, could you explain?
MuseScore provides control over spacing because different people have different preferences. The defaulty is chosen to be a little on the tight side on the assumption that you will simply add line breaks where you want, this is much easier than erring on the side of being too loose and forcing people to resort to stretch adjustments. But if you personally prefer looser by default, feel free to up it in your own scores.
Increasing the measure spacing to all the way 2.0 most definitely is not anything remotely resembling the MuseScore 2 default. The MuseScore 2 default was 1.2 just like MuseScore 3. While limitations to the MuseScore 2 layout caused it to be considerably less smart about use of space than MuseScore 3, overall number of measures per line should be pretty similar. if you have a particular MsueScore 2 scores that you need to crank all the way up to a spacing of 2.0 in MsueScore just to get it to look similar, something is seriously wrong, so we'd need you to attach the score to investigate.
Minimum staff distance is not relevant to any score that fits on one pages. It's main purpose is to figure out how many staves can fit. Once that is decided, it's the max distance that controls the end result. This is not changed from any previous release, it's the way MuseScore has worked since 1.0 at least.
If you want the systems space further, then yes, increase maximum staff distance - that is it's main purpose. Not sure why you think it would lead to crowding? Quite the contrary, all it does is open up more space. Again, exactly as in every previous release - except MuseScore 3 actually increase system and staff distance automatically enough to avoid collisions.
The collision in 26 is because you disabled autoplace, so of course it isn't doing its job.
In reply to As I said before, yes,… by Marc Sabatella
Perhaps the display is not the same for everyone, so here are three PDF files, with 18 measures each, with all default conditions. All are for A4 paper size, same default left and right margins. Both MS versions are with the default staff spacing (1.764 mm) and the same default measure spacing (1.200). I have also added an MS 2 file; the MS 3 file is from the first post.
"When you say you feel the "lines" are crowded or expanded, I am not sure what you mean, could you explain?"
Lilypond: 6 measures/line; MS 2: 7 measures/line; MS 3: 9 measures/line. Look at the first two lines. MS 2 and Lilypond look all right. With MS 3 the notes are obviously closer together, and look crowded to my eye.
"Increasing the measure spacing to all the way 2.0 most definitely is not anything remotely resembling the MuseScore 2 default."
On my computer with MS 3, a spacing of 1.7 to 2.0 gives 7 measures/line, approximately the same as MS 2 with a spacing of 1.2. A spacing of 2.2 in MS 3 is required to match Lilypond at 6 measures/line.
"If you have a particular MuseScore 2 score that you need to crank all the way up to a spacing of 2.0 in MsueScore just to get it to look similar, something is seriously wrong, so we'd need you to attach the score to investigate."
No, it's the other way around. 1.7 to 2.0 in MS 3 matches 1.2 in MS 2. An MS 2 score is attached; the score in the very first post is from MS 3. I believe all the settings are default values, but you can certainly check.
"Minimum staff distance is not relevant to any score that fits on one pages. It's main purpose is to figure out how many staves can fit...."
OK, that solves that problem. Thank you.
"The collision in 26 is because you disabled autoplace, so of course it isn't doing its job."
But if I enable it, I get a very badly formed slur, as in measure 8.
In reply to Perhaps the display is not… by RexC
Ah, so by "line" you mean "system" - that is what I wasn't getting.
So, the be clear nothing has actually changed in any significant way about how note spacing works (which is the prime determinant of the number of measures fit on any given system. I get that you are saying you need to increase spacing to 2.0 in MuseScore 3, that's what I said before - but what I'm also saying is, that's highly unusual. The vast majority of scores will show no such difference, or in some cases a slightly different in the other direction.
As I said before, some of the bugs and quirk of MuseScore 2's layout have been addressed, allowing MuseScore 3 to be smarter about spacing in some cases, and occasionally this does indeed lead to slight differences. In your case here, it seems that slight differences add up to be enough to fit two more measures on the system, , but that's quite rare. In those unusual cases like this where the default ends up being on the tight side, as I said, simply increase the spacing setting, or add line breaks. Same approach as in MuseScore 2,
Regarding vertical spacing between staves / systems, only one thing has changed significantly regarding how staff/system spacing: the fact that MuseScore now automatically increases distance as needed to avoid collisions. If there were no collisions in MuseScore 2, there will be no difference in vertical spacing. If there were collisions in MuseScore 2, then MuseScore will add space to eliminate them. And in any case, the system distances are entirely under your control, in both versions, using the min/max distance settings.
And yes, turning off autoplace results in collisions. That is the whole point of autpalce - to resovle the many collisions that used to happen in MuseScore 2. For slurs specifically, the default layout hasn't actually changed much at all. We try to draw the slur in the same we always have, but if a collision is detected, we try moving the slur up (or down, for downward slurs) to avoid the collision. If that results in the slur getting too far from the noteheads, we try bending the slur more. Often this produces great results. In a few corner cases like these - especially where there are very tightly spaced jumps - it results in these weird way-too-curved slurs. The algorithm that tries increasing the curvature to avoid the collisions and also too-far-away slurs can no doubt stand to be improved, maybe with additional customization to set a maximum curvature, etc. Meanwhile, as mentioned, simply disable autoplace, then and you're back to where you would have been in MuseScore 2 and are free to resolve the collision manually as you always did in the past. In the many cases where the collision avoidance works perfectly, you don't have to lift a finger, in the few where it produces weird results, it's a single click to get back to the old method.
In reply to Ah, so by "line" you mean … by Marc Sabatella
I have checked a few scores. You're right, the horizontal spacing does vary a lot. Still, the difference between 6 and 9 measures/line is considerable. And I find that with version 3 the notes are rather crowded unless I increase the staff spacing. My problem is solved, but for best appearance of the default output, you might want to consider increasing the default spacing. I suggest a value between 1.4 and 1.7.
I agree, it might be a good idea to modify the algorithm to limit the curvature of slurs.
I agree, autoplacement has improved placement in some cases. In other cases I'm not so sure, but that's a topic for another discussion.
Thanks for your consideration and help.
In reply to I have checked a few scores… by RexC
I think if you try a wider variety of scores, you will discover that values higher thn 1.4 are almost always too much. In any case, there is clearly no one-size-fits-all answer here, so like I said, we err on the side of beong too tight in some cases because adding line break is much simpler than needing to resort to stretch.
In reply to I think if you try a wider… by Marc Sabatella
I did try some other scores from this web site. It's odd. Some scores render virtually identically in MS 2 or 3, and some don't. But I see there are many default settings that are not the same, and I'm not going to try to (and don't need to) troubleshoot further.
I still encourage fixing those slurs.
Thanks for your diligence in answering all these messages.
In reply to I think if you try a wider… by Marc Sabatella
You're quite right. The effect of measure spacing is inconsistent. I'm not sure changing the default setting would solve anything. The problem might be related to this: https://musescore.org/en/node/299741 .
Do I need to file any paperwork in regard to the slurs?
In reply to You're quite right. The… by RexC
The effect of measure spacing isn’t inconsistent at all - raising it increases, lowering it decreases it, as one should expect. And the issue described in that other thread applies to MuseScore 2 in the same way, so that’s consistent too.
What’s inconsistent is whether the differences between 2.x and 3.x happen to work out to cause 3.x to take more or less than 2.c by default. That’s because 3.x really cured a lot of problems in 2.x - some of which caused 2.x to add too little space (resulting in collisions), some of which caused it to allocated too much space in an effort to avoid problems it couldn’t detect.
As for slurs, there are already outstanding suggestions in the issue tracker for further improvements the autoplace algorithms for slurs, feel free to just add your comments there.
In reply to The effect of measure… by Marc Sabatella
"The effect of measure spacing isn’t inconsistent at all - raising it increases, lowering it decreases it, as one should expect. And the issue described in that other thread applies to MuseScore 2 in the same way, so that’s consistent too."
Sometimes 1.2 is just right, but sometimes 1.2 is way too crowded. That's what I mean by inconsistent. But on cursory examination it appears that what I'm seeing is what Barnie Snyman has reported. I notice your work on this, and it is much appreciated.