On Fri, Apr 27, 2012 at 6:05 PM, Urs Liska
<address@hidden> wrote:
Am
27.04.2012 19:30, schrieb David Nalesnik:
it's not only this. I think that with any slur that one might decide
to shape manually a change in line break will spoil it anyway. So
I'm not so sure it's a useful goal to make such a function
fool-proof in this respect.
Well, the file fails (at least lilypond says so), but it actually
compiles, it's only the function that isn't applied. But you're
right to assume that the normal user can't cope with the error
messages ;-)
If that's possible in such functions, I'd find it very useful. Even
better: tell the user: "The slur has now X parts, please adapt the
function call"
First: I think this is a _very_ useful function that should even be
made more widely known.
I'm very glad that you think so!
Second: your syntax suggestion looks very good to me.
Of course it is more to type. But that is more than outweighed by
the advantages. it's easier to write and it's especially much easier
to read. When changing the offsets (which you do multiple times
until you get a good result ...) I'm always finding me counting
params (in order to find the right item to change) which surely
takes more time and concentration than typing (once) a few brackets
and points.
Yes, I also find it very easy to make mistakes when typing in lists separated only by spaces. Trying out examples for the attached file, I was pleasantly surprised at how much easier-- and faster! -- it is to use the alist notation. Certainly, it is easier to read. Plus, I think it makes the offsetting function a bit less ugly.
Third: I suggest to add support for PhrasingSlurs and Ties in order
to make it more general. For PhrasingSlurs it's just a matter of
writing a new entrance function, but for Ties you need new
shape-ties and alter-tie-curve subroutines. See the attached file
that is the result of an earlier enquiry on this mailing list.
The functions themselves don't incorporate your newest additions
(sorry, it's still a bit over my head), but you'll see what I mean.
One solution is to use a syntax like this:
\shapeCurve #"Tie" #'( ((dx1 . dy1) . . . ))
and then to let the functions choose the right control-points callback from a list based on the name of the grob you're overriding. (Dmytro used this in a variant of his adaptation which I saw off-list.)
I thought it might be nice to have \shapeSlur, \shapeTie, etc. To avoid duplicating so much code, I pass the relevant 'control-points callback to the functions which need it. Of course, you can extend this list to whatever takes control-points. As you mention, \shapePhrasingSlur would be the same as \shapeSlur. You can do \shapeTupletBracket in 2.14.2, but it looks like 'control-points is gone in 2.15.
to sum up what I said:
If you'd volunteer to do the following it would be a very valuable
contribution to LilyPond's usability ;-)
I'd be delighted to do whatever I can.
- let the function check the number of arguments and give meaningful
warnings instead of errors
(count arguments and compare against number of slur siblings)
It will do this. In the attached examples, some warnings will appear, and you can add elements and comment them out (with ; inside of the Scheme _expression_ instead of the ordinary %) Tell me what you think!
- don't try to make the function robust so that it accepts wrong
input. This may be trivial from a programmer's perspective but I
can't imagine that it makes sense aesthetically.
It won't work at all if you write:
\shapeSlur #'()
\shapeSlur #'( () )
will work. The () is a shorthand for "leave this segment alone".
You can write either:
\shapeSlur #'( (dx1 . dy1) . . . )
or
\shapeSlur #'( ((dx1 . dy1) . . . ) )
You'll get wacky results if you don't include enough pairs.
Thank you very much for your input. It would be great if you could try this out and see if it does what you want!
Best,
David