Hi Urs, On Fri, Apr 27, 2012 at 6:05 PM, Urs Liska <li...@ursliska.de> wrote:
> Am 27.04.2012 19:30, schrieb David Nalesnik: > > Hi Urs, > > On Fri, Apr 27, 2012 at 11:46 AM, Urs Liska <li...@ursliska.de> 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. > 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
shaping-curves.ly
Description: Binary data
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
