Re: is shapeSlur broken?

[Urs Liska]

Am 27.04.2012 19:30, schrieb David Nalesnik:

Hi Urs,

On Fri, Apr 27, 2012 at 11:46 AM, Urs Liska <address@hidden> wrote:

Hi David,

thank you for now. I'll look into it.
But isn't it very likely that I have to reshape a slur anyway when it changes from  broken to unbroken?
In that case I'd even say the errors are a 'feature' so you notice it ...
Provided it is documented enough not to drive you crazy ...

Sure, that's true.  Presumably when you're looking for that fine control, you've settled on the layout in all but the tiny details! 

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.

Without the modification, though, the error would cause the file to fail and the error message is a little opaque.  (Well, it's quite exact, but it takes some study to figure out how it happened.)

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 ;-)

I could create a warning here, something like: "slur is not broken anymore".

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"

One thing you can do is
\shapeSlur #'( ... list of offsets ...)
or
\shapeSlur #'(( ... list of offsets ...))

without the file failing.

Since this function has come up again, I wonder if I could get your (and other people's) opinion on syntax.  When I first wrote the offsetting function (http://lsr.dsi.unimi.it/LSR/Item?id=639)I thought that alists were a bother to type.  But 'control-pojnts _is_ an alist '((x1 . y1) (x2 . y2) ... )) , so shouldn't we have something like this?

\shapeSlur #'((dx1 . dy1) (dx2 . dy2) ...)

I realize that there's more to type, but wouldn't this be clearer to use? (As well as being more consistent with how LilyPond represents this type of data)?

First: I think this is a _very_ useful function that should even be made more widely known. The need to shape slurs is one of the most important issues when it comes to the major problems of a LilPond score. Not because it's a deficit of LilyPond but because it's a very complex topic that needs human intervention in most cases.

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.

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.

Any thoughts?

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 ;-)
- let the function check the number of arguments and give meaningful warnings instead of errors
(count arguments and compare against number of slur siblings)
- 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.
- add support for phrasingSlurs and ties
- make all this visible, at least through an updated snippet in the LSR. Personally I think this should also be in the docs.


With best wishes
Urs

-David

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user

shapeXXX.ily
Description: Text document