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!
shaping-curves.ly