On 21.09.2016 18:22, Urs Liska wrote:

Maybe the below message will get through later, but maybe it's blocked because of the attachement size, so I resend it with the attachments uploaded to

https://cloud.ursliska.de/index.php/s/km6cHCuuMF7AcWt and

Urs, this is totally awesome! Many thanks :-) I’ll have to review the interface, but these examples are so promising…
Best, Simon

(these may not be permanent!)


Am 21.09.2016 um 18:01 schrieb Urs Liska:

Hey all,

I wouldn't claim production readiness yet, but I've gone a long way with multi-segmented slurs :-)

As you can see from the attached PDF files (if they don't block the message from being delivered ...) we can now print slurs with an arbitrary number of connected segments! The slur in the first system is along the lines of the orginal print, and I've added a "fancy" example with the red slur in the lower system.

Of course it's somewhat tedious to finetune these slurs, but I found it's surprisingly convenient to do, and with little surprises. The critical point is that the segments are completely independent -with the exeption of the forced equal angle at the inflection points. So what one basically does is add one inflection point after another, and one can independently tweak the slur to the left of each inflection point, without serious side-effects.

I've completely disposed of any "offset" specification except for the positioning of the two ends. For all the control point editing you will give it an angle (which is relative to the baseline of the segment) and a ratio (in relation to the length of that baseline). This gives very predictable results and makes tweaking as easy as one can expect with such complex notation. Of course this even more begs for a graphical tweaking interface ... But of course this function is substantially more reliable than anything you can do with other tools.

I don't copy the whole code into the email anymore, the sources are now at https://github.com/openlilylib/snippets/tree/compound-slur/notation-snippets/shaping-bezier-curves, in the files compound-slurs.ily and common-math-and-stencils.ily. I'll go through another round of tidying up, but I'm happy about any suggestions to improve the code.

To give an idea about the interface, this is the definition of the (first few inflections of the) upper Sorabij slur:

^\compoundSlur \with {
  annotate = ##t
%  show-original-slur = ##t

  start-point = #'(0 . 3)
  start-angle = 65
  start-ratio = 0.6
  end-point = #'(2.5 . 4)
  end-angle = -70

  inflection =
  #'((point . (.215 . 1.55))
     (angle . -55)
     (ratio-left . 0.4)
     (ratio-right . 0.22))

  inflection =
  #'((point . (.26 . -0.2))
     (angle . 60)
     (ratio-left . .45)
     (ratio-right . .4))

  inflection =
  #'((point . (.49 . 0.35))
     (angle . 33)
     (ratio-left . .45)
     (ratio-right . .15))

% ...

So you give a few general properties for the start and end points and then each inflection as an individual unit. The "point" is the ratio between the end points of the slur. Angle is given relative to the *left* base-line (and the spline to the right will exactly mirror that value). ratio-left and ratio-right specify the length of the two handles around the inflection point.

I think it's already pretty clean with regard to type checking and falling back to defaults for missing or wrong-type properties (while issuing a warning).

If you want to try it out you will have to have scholarLY installed separately, in the version from https://github.com/oll-core/scholarly. But it may be worth the effort, as it also demonstrates one of the GSoC news: triggering footnotes from annotations.

So far I have the impression it works very well, with some minor and not-so-minor glitches.

The minor one is that I'd like to specify the starting point relative to the note head instead of to LilyPond's default decision. I think whenever such compound slurs are necessary LilyPond's default slur will be completely irrelevant to us, and we can instead specify the end points explicitly anyway. \shapeII already has this as an option, so I'll look for that.

One larger thing is that I don't support broken slurs yet (and I won't go after that right now - hopefully someone else chimes in now).

The other thing I came across is the specification of the inflection *point*. Basically the idea of specifying independent X and Y ratios between the slur's endpoints seems practical, as it is pretty predictable. But I realized that this only works well when the endpoints are sufficiently different on the Y-scale. If the slur is horizontal then *any* inflection will necessarily be on that same horizontal line! So I need a suggestion what could be a suitable, predictable *and* un-limited approach to specifying this.

Another minor wish I would like to implement is printing an optional grid which will ease finding the right inflection points, and maybe a raster along the handles (going beyond their current length. This would make it much easier to find the right values for these.

Have fun


Am 20.09.2016 um 13:53 schrieb Trevor Daniels:
Impressive work, Urs!  Kudos!

    ----- Original Message -----
    *From:* Urs Liska <mailto:u...@openlilylib.org>
    *To:* lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
    *Sent:* Monday, September 19, 2016 11:40 PM
    *Subject:* Re: What to do wanting a 4th order Bézier?

    Am 19.09.2016 um 22:49 schrieb Urs Liska:
    Am 19.09.2016 um 20:50 schrieb David Kastrup:
    Urs Liska<u...@openlilylib.org>  writes:


    You are working with slopes here.  Don't.  They don't support vertical

    Yes, that's what I realized ...

    Please take a look at the recently added functions

        ly:length ly:angle ly:directed

    They will usually make it easy to do the operations you want.  In
    particular ly:directed can also use a vector as a direction without ever
    calculating its angle.
    Thanks! From looking at the docs it seems they'll do exactly what I want
    (and had partially implemented in Scheme). Can't wait to return to my
    LilyPond computer :-)

    I think I now have it in a state where we can work from. The
    angle of the inflection is now given as an angle relative to the
    line connecting the end points of the whole slur. While an angle
    relative to the horizontal line would be somewhat more
    straightforward I think this approach is more robust against
    changes (for example when the slur is cross-staff and the
    staff-staff distance changes).


      * support more than two segments
        (shouldn't be *that* difficult, just tedious and slightly
      * support broken slurs
        (each sibling should be togglable between multi-segment or
        not, and it should be \shape-able)
      * support Slur, PhrasingSlur and Tie (like \shape)
      * specify shapes as polar coordinates (or all options that
        \shapeII has)

    The code is now at


    lilypond-user mailing list

lilypond-user mailing list

lilypond-user mailing list

Reply via email to