Bloated slurs and other slur-related issues

[fablau]

Hello @sschmidTU and team,
Here is another issue involving slurs.

Have a look at the attached XML file. Most of the slurs are drawn correctly, but some of them are too strange.

Take for example, bars 36-37:

The slur there is exagerately bloated for some reason.

The previous bar is also a little bit too inflated at the bottom:

And look at bars 49-50:

And again, in bars 63-65:

I understand OSMD is not perfect yet in drawing slurs, but I am wondering if there is a way to avoid such a "bloating" or, at least, to reduce it in some way?

That's the main issue I see for slurs, but there are other minor things that could be improved, such as avoiding their start and end positions to go over beamings. Look at the following examples:

Bar 5, the first slur starts under the beaming; the other ones should finish before "touching" the beam:

Bars 30-31, you can see the same start-ending issue shown more prominently:

Again, I understand these are probably "little displacements" and we could just ignore them, but the more I use OSMD, the more I see how little is needed to make it perfect ;)

We are almost there!!

As always, I am eager to know your thoughts about this issue. Thank you for listening. :)

I am attaching the source MusicXMl file.

01Adagio_sostenutoPANO2.musicxml.zip

[sschmidTU]

This is a complex issue that only happens in specific/complex scores, and yes, we've planned on improving this for some time.
But to give you a quick answer for now, for the big slur arcs, I can recommend to play around with some of the EngravingRules a bit.
The default rules are good for almost all short slurs and non-complex scores, but often get in trouble with complex piano scores with very long slurs.

    public SlurSlopeMaxAngle: number;
    public SlurTangentMinAngle: number;
    public SlurTangentMaxAngle: number;
    public SlurHeightFactor: number;
    public SlurHeightFlattenLongSlursFactorByWidth: number;
    public SlurHeightFlattenLongSlursFactorByAngle: number;
    public SlurHeightFlattenLongSlursCutoffAngle: number;
    public SlurHeightFlattenLongSlursCutoffWidth: number;
    public SlursStartingAtSameStaffEntryYOffset: number;
    public SlurMaximumYControlPointDistance: number;

There might be a few more I've missed.
Maybe SlurSlopeMaxAngle and SlurHeightFlattenLongSlursFactorByWidth / angle could be the most effective for quick tuning.

[sschmidTU]

By the way, this issue is mostly a duplicate of #971.

[fablau]

Thank you Simon! I'll play with that and see if I can do anything in the code to improve it so as to handle everything better automatically ;)

[sschmidTU]

Nice, let me know if you've found some good settings!
The ideal solution will be more fundamental of course. I've been thinking about adding more control points to the bezier curve, like one in the middle, and maybe also one a bit more early.
The algorithm is basically trying to avoid collisions, and if one would happen very early in the curve, it has to start with a high arc to move around it. That's the issue I think.

[fablau]

Yes, of course, I'll let you know. It'd be nice to implement, looking forward, an algorithm to avoid any kind of collision, similar to the "magnetic layout" feature in Sibelius. Hard to think how to do it, but that could be a good goal to fix a lot of problems.

[fablau]

Simon, from my testing, it looks like the "SlurTangentMaxAngle" setting is the only one that can help with that issue. The only problem is that lowering the curvature causes overlap issues with fingerings or other symbols/text over or under the notes.

I am wondering if OSMD is considering any of the Y positioning attributes defined in the MusicXML protocol for sure as explained here:

https://www.w3.org/2021/06/musicxml40/musicxml-reference/elements/slur/

In particular, the "default-y" and "relative-y" attributes that, if considered, could allow the position of slurs at a more granular level and on a "per-slurs" basis. From a quick search into the code, I don't see that happening.

And about the curvature, are the "bezier" related attributes considered at all by OSMD? I couldn't find any reference to those attributes either.

[sschmidTU]

default-y is generally useless, as it's an absolute value and our positions and sizes are different.
relative-y might be interesting for problematic slurs in particular. The issue is: When do you know that a slur is problematic?
The bezier attributes might also be interesting, though I somehow doubt Sibelius will give reasonable values.
Definitely some points to look at.

[fablau]

Good points Simon... well, the only thing I can think of about using the relative-y value is to change that in the MusicXML code on an "as-needed" basis. In other words, let's say I see a slur rendered wrongly, I can modify the XML file to give that slur a Y position in order to look better.

And I see what you mean about Sibelius not handling that, but I personally wouldn't care. Exporting files from Sibelius, in my case, is just a starting point. But if I can then handle the MusicXML files myself, via Javascript, and define those values as I like, then resubmit them to OSMD being sure that OSMD will evaluate them and use them correctly, that'd be simply great and that'd be what I'd really like to be able to do ;)

[fablau]

Here I am again with a question related to this issue: is there a way to control the arc or the slur positioning on a "slur-by-slur" level? And not by changing the engraving rules that would affect "all" slurs on the score? What I mean is if there is a way to tell OSMD to redraw a specific single slur according to specific parameters. I am asking this because it'd be neat if we could control the display of single slurs on an "as-needed" basis. I am working on a project that would allow the user to "edit" the shown score somehow, but I am struggling to understand if OSMD has any way to allow external display control of objects (and so of slurs as well) at a discrete level.