Am 18.09.2016 um 22:16 schrieb Thomas Morley:
> 2016-09-18 20:26 GMT+02:00 Urs Liska <u...@openlilylib.org>:
>> Am 18.09.2016 um 18:28 schrieb Simon Albrecht:
>>> May I incorporate that into the LSR version?
>> I suggest not to do anything right now. I assume that once I'll come up
>> with the next iteration there will be more things to be discussed. I
>> suggest to bring that to an end before deciding what to do with it.
>> Maybe it would be good to include to LilyPond itself instead of the LSR.
> Hi all,
> I have my doubts we will ever find a possibility to do it reasonable
That's probably right. But I don't think that should necessarily prevent
us from including it as a built-in tool. This kind of slur will always
be a corner case of notation, and noone would expect a notation software
to handle it automatically. However, with something like we're building
here LilyPond will solve the problem better than the competition by
orders of magnitude.
Take m. 4 of the Ravel on p. 6 of
as an example. The (manually tuned) rendering of LilyPond on
is already better than Finale (IMO), but the point is that the Finale
solution is completely fragile when it comes to modifications of the layout.
> What to do at linebreaks or if more than two splines are needed?
I think when we've settled about how to specify the compound slur it
won't be too complicated to find a solution where multiple splines can
be created when more than two sets of controls are given.
Handling at line breaks should be possible as well, and when an
(originally single) compound slur happens to be broken, a warning should
be sufficient (like with \shape).
Maybe it would be a good idea not to implement compound slurs as a
command but rather as an overridable property of the slur/tie/phrasingslur:
\once \override Slur.compound = ...
> You probably already know the most extreme case, from Sorabji's Opus
> Clavicembalisticum (1930):
> The paper where the image is taken from lists some more extreme notations:
lilypond-user mailing list