Re: is shapeSlur broken?
Hello Harm and list,
thank you very much for this function! I really like it :-)
Now I just wanted to share my way to shorten the input:
\shape #'(((0 . 0)(0 . 0.3)(0 . 0.3)(0 . 0)))
is a long thing to type. Most times I only want to adjust the y-part of
the two inner control-points - sligtly. So I use the following:
--snip--
\version 2.15.38
% predicate for a number or a list of numbers
#(define (number-or-list? v)
(or (number? v)
(and
(list? v)
(eval `(and ,@(map (lambda (x)`(number? ,x)) v))(interaction-environment))
)))
% shape function, that only touches y-parts of the two inner control-points
ty = #(define-music-function (parser location grob dy)(string?
number-or-list?)
; extract scheme-function from shape, to provide location of \ty
(let ((shape-fun (ly:music-function-extract shape)))
(shape-fun parser location grob
(if (list? dy)
(map (lambda (y) `((0 . 0)(0 . ,y)(0 . ,y)(0 . 0)) ) dy)
`((0 . 0)(0 . ,dy)(0 . ,dy)(0 . 0))
)
)))
\relative c'' {
\ty Tie #'.4 c1 ~ \ty Tie #'(0.4 0) c ~ \break c
}
--snip--
We can provide functions, where the control-point-modification is
calculated.
In this example, I use ly:music-function-extract to have a
scheme-function, that takes the location this shortcut happening. If you
use #{ \shape ... #}, any warnings will be shown for the inline code -
not the location where \ty (or whatever you call your function) is
called. This should be intended behaviour, but it is good to know.
Cheers, Jan-Peter
On 11.05.2012 00:50, Thomas Morley wrote:
Hi David,
I thought a while about your function.
I'd like to suggest some changes. In the attached file you can see:
- Elimination of `function' as argument of shape-curve and introducing
it as local variable.
- A new condition added in shape-curve at the siblings-variable: ly:spanner?
- In the music-function I added a new variable to specify the grob.
These give the advantage to define only one music-function.
Of course there is need to specify which grob should be applied.
But now it works for all curves:
Slur
PhrasingSlur
Tie
RepeatTie
LaissezVibrerTie
I didn't test it very widly, but what do you think?
Best,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Jan-Peter Voigt jp.vo...@gmx.de writes: Hello Harm and list, Could you try _not_ posting in HTML? This mail had both a plain text as well as an HTML-specified part, and both rendered awfully here. If you send just as plain text, chances are that you see what you are actually sending. \version 2.15.38 % predicate for a number or a list of numbers #(define (number-or-list? v) (or (number? v) (and (list? v) (eval `(and ,@(map (lambda (x)`(number? ,x)) v))(interaction-environment)) ))) What is the crazy idea with using eval? Why don't you use (every number? v) here? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
On 14.05.2012 12:34, David Kastrup wrote: Jan-Peter Voigtjp.vo...@gmx.de writes: Hello Harm and list, Could you try _not_ posting in HTML? This mail had both a plain text as well as an HTML-specified part, and both rendered awfully here. If you send just as plain text, chances are that you see what you are actually sending. ups, sorry! It was the last thunderbird update, or whatever ... \version 2.15.38 % predicate for a number or a list of numbers #(define (number-or-list? v) (or (number? v) (and (list? v) (eval `(and ,@(map (lambda (x)`(number? ,x)) v))(interaction-environment)) ))) What is the crazy idea with using eval? Why don't you use (every number? v) here? ... because I sometimes don't see the obvious ... ;-) thank you! I sometimes like to change only the inner and sometimes also the outer ones, so I have a number or a pair of numbers and a predicate, that looks for one of them. But I thought, it is easier to explain just one case ... still I could have used (every): --snip-- (define (number-or-list? v) (or (number? v) (number-pair? v) (and (list? v) (every (lambda (x) (or (number? x)(number-pair? x))) v) ))) --snip-- This might still be ugly, but it works for me - so its OK ;-) Cheers, Jan-Peter ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Jan-Peter Voigt jp.vo...@gmx.de writes: On 14.05.2012 12:34, David Kastrup wrote: Jan-Peter Voigtjp.vo...@gmx.de writes: Hello Harm and list, Could you try _not_ posting in HTML? This mail had both a plain text as well as an HTML-specified part, and both rendered awfully here. If you send just as plain text, chances are that you see what you are actually sending. ups, sorry! It was the last thunderbird update, or whatever ... \version 2.15.38 % predicate for a number or a list of numbers #(define (number-or-list? v) (or (number? v) (and (list? v) (eval `(and ,@(map (lambda (x)`(number? ,x)) v))(interaction-environment)) ))) What is the crazy idea with using eval? Why don't you use (every number? v) here? ... because I sometimes don't see the obvious ... ;-) thank you! No, it is not just that. Using eval is a recipe for trouble because it runs at a time where the actual lexical environment you are evaluating this in is _gone_. It also adds a _spurious_ layer of evaluation, so anything but self-evaluating expressions in the list will fail with the weirdest of consequences. eval is a _very_ special tool with a _lot_ of strange consequences. On par with self-modifying code in assembly language. When you need its special effects, namely creating a new interpretative environment and _interpret_ something in this environment _completely_ detached from the code around it, its use may be called for. But it is not the first time I have seen you propose the use of eval where it makes absolutely no sense at all calling a complete encapsulated Scheme interpreter instead of using the interpreter/compiler already dealing with the surrounding expression. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
David Nalesnik david.nales...@gmail.com writes: So: \shape #Slur #'( ... Looks awful. Why not call it with the syntax used for any override? \shape Slur #'( ... -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
So: \shape #Slur #'( ... Looks awful. Why not call it with the syntax used for any override? \shape Slur #'( ... Yes, it is pretty horrible. I didn't realize that LilyPond would accept strings not enclosed in double quotes. Thanks, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
On Thu, May 10, 2012 at 6:53 PM, Thomas Morley
thomasmorle...@googlemail.com wrote:
Hi David,
2012/5/11 David Nalesnik david.nales...@gmail.com:
I don't have 2.14.2 up to test, but this all should work there provided
you
add the # before the string?
So:
\shape #Slur #'( ...
I was wrong here. You can use \shape Slur . . . there too.
I tested what's needed to make it work with 2.14.2 (therefor the
2.14.2-version-number in the file).
Well, you can boil down the main-function quite easily, but
`ly:input-warning' is not part of 2.14. Deleting the whole
warning-part would mean a considerable loss of functionality.
Here you can substitute ly:input-message (which doesn't stand out as well).
Just for the record, to make this work in 2.14.2, you need to add dollar
signs before the variables in the music function. So:
shape =
#(define-music-function (parser location grob offsets)
(string? list?)
#{
\once \override $grob #'control-points =
#(shape-curve $offsets $location)
#})
And I didn't think about an alternative for 2.14.2, hoping for 2.16 coming
soon.
Should be just around the corner!
-David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
David Nalesnik david.nales...@gmail.com writes: Should be just around the corner! We just had another fix for a critical regression in, and I marked updating the \footnote documentation to \footnote behavior (\footnote is now used as a postevent consistently) also as Critical. Once the release candidate gets out, we have a delay of two weeks for other critical regressions to be found. I certainly hope that we get through that without new regressions being found, but it is not like that hope would be particularly novel. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Am 11.05.2012 01:27, schrieb David Nalesnik:
Hi Harm,
On Thu, May 10, 2012 at 6:00 PM, Thomas Morley
thomasmorle...@googlemail.com mailto:thomasmorle...@googlemail.com
wrote:
2012/5/11 Thomas Morley thomasmorle...@googlemail.com
mailto:thomasmorle...@googlemail.com:
Hi David,
I thought a while about your function.
I'd like to suggest some changes. In the attached file you can see:
- Elimination of `function' as argument of shape-curve and
introducing
it as local variable.
I like this! I had thought of looking up the callback (as an
alternative to passing it in), but hadn't found a way to do it. Nice!
- A new condition added in shape-curve at the siblings-variable:
ly:spanner?
Right--otherwise overriding LaissezVibrerTie won't work.
- In the music-function I added a new variable to specify the grob.
Aha--I didn't realize you could drop the # in the latest versions. I
like this too. Of course, if you want to stick with shapeSlur (and
its ilk) you can define it like this:
shapeSlur =
#(define-music-function (parser location offsets) (list?)
#{
\once \override Slur #'control-points = #(shape-curve offsets
location)
#})
I would prefer this one, although it needs a lot of individual functions
be defined.
But there should be no problem in defining the shapeXXX set of function
parallel to a \shape XXX #'( version).
I hope I'll find the way how to update #(display-control-points) (from
the other thread on bug-lilypond) so it works with the other curve types
too.
Best
Urs
These give the advantage to define only one music-function.
Of course there is need to specify which grob should be applied.
But now it works for all curves:
Slur
PhrasingSlur
Tie
RepeatTie
LaissezVibrerTie
I didn't test it very widly, but what do you think?
I like it all.
Oops, forgot to delete the wrong version-number..
Please switch to \version 2.15.36 or higher.
I don't have 2.14.2 up to test, but this all should work there
provided you add the # before the string?
So:
\shape #Slur #'( ...
Thanks so much!
Best,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hello David, hello Urs,
thank you very much for these improvements!
I have a tiny addition: PhrasingSlurs
--snip--
shapePhrasingSlur =
#(define-music-function (parser location offsets)
(list?)
#{
\once \override PhrasingSlur #'control-points =
#(shape-curve offsets ly:slur::calc-control-points location)
#})
--snip--
Cheers, Jan-Peter
On 09.05.2012 18:42, David Nalesnik wrote:
Hi Urs,
On Wed, May 9, 2012 at 10:13 AM, Urs Liska li...@ursliska.de
mailto:li...@ursliska.de wrote:
Hi David,
now I tested your new function.
OK, I didn't test more than the sources you provided, but I think
they give all the necessary combinations.
So my conclusion is: This is awesome!
I won't ever live without this (as long as LilyPond is concerned)
anymore - as long as it won't get broken by new versions.
Great! I'm very happy to hear this!
One idea to make it even more comfortable and generic to use would
be not to hard-code the color within the function.
If one could somehow set the color outside the function one could
personalize it to ones needs.
As this is kind of a library thing, I think it isn't necessary to
make this settable at runtime through the function call.
Maybe one could define a variable for the color above the
function, setting #black as default.
Then anybody can easily see how to adapt it even if she/he doesn't
understand the function itself.
Ah, I just realized that this way one could still set the color in
the music source by redefininge the variable ...
I would be happy about this enhancement.
But I really have to admit that this is quite low priority because
the function is already extremely helpful.
This isn't difficult to do. As you say, you could define a variable
for color above the function. All you would need to do then is
replace red with the name of the variable in the two places it occurs.
In the attached file, I do this and give several ways of specifying
the color you want. (Of course, it's the last definition that is
actually used.)
Best and thanks again
Urs
You're very welcome!
Best,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi Jan-Peter,
thanks for this.
I had already inserted phrasingSlurs into the function, but somehow they
slipped through the net during some update ...
Best
Urs
Am 10.05.2012 09:59, schrieb Jan-Peter Voigt:
Hello David, hello Urs,
thank you very much for these improvements!
I have a tiny addition: PhrasingSlurs
--snip--
shapePhrasingSlur =
#(define-music-function (parser location offsets)
(list?)
#{
\once \override PhrasingSlur #'control-points =
#(shape-curve offsets ly:slur::calc-control-points location)
#})
--snip--
Cheers, Jan-Peter
On 09.05.2012 18:42, David Nalesnik wrote:
Hi Urs,
On Wed, May 9, 2012 at 10:13 AM, Urs Liska li...@ursliska.de
mailto:li...@ursliska.de wrote:
Hi David,
now I tested your new function.
OK, I didn't test more than the sources you provided, but I think
they give all the necessary combinations.
So my conclusion is: This is awesome!
I won't ever live without this (as long as LilyPond is concerned)
anymore - as long as it won't get broken by new versions.
Great! I'm very happy to hear this!
One idea to make it even more comfortable and generic to use
would be not to hard-code the color within the function.
If one could somehow set the color outside the function one could
personalize it to ones needs.
As this is kind of a library thing, I think it isn't necessary to
make this settable at runtime through the function call.
Maybe one could define a variable for the color above the
function, setting #black as default.
Then anybody can easily see how to adapt it even if she/he
doesn't understand the function itself.
Ah, I just realized that this way one could still set the color
in the music source by redefininge the variable ...
I would be happy about this enhancement.
But I really have to admit that this is quite low priority
because the function is already extremely helpful.
This isn't difficult to do. As you say, you could define a variable
for color above the function. All you would need to do then is
replace red with the name of the variable in the two places it
occurs. In the attached file, I do this and give several ways of
specifying the color you want. (Of course, it's the last definition
that is actually used.)
Best and thanks again
Urs
You're very welcome!
Best,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi David, I thought a while about your function. I'd like to suggest some changes. In the attached file you can see: - Elimination of `function' as argument of shape-curve and introducing it as local variable. - A new condition added in shape-curve at the siblings-variable: ly:spanner? - In the music-function I added a new variable to specify the grob. These give the advantage to define only one music-function. Of course there is need to specify which grob should be applied. But now it works for all curves: Slur PhrasingSlur Tie RepeatTie LaissezVibrerTie I didn't test it very widly, but what do you think? Best, Harm shaping-curves03-rev.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
2012/5/11 Thomas Morley thomasmorle...@googlemail.com: Hi David, I thought a while about your function. I'd like to suggest some changes. In the attached file you can see: - Elimination of `function' as argument of shape-curve and introducing it as local variable. - A new condition added in shape-curve at the siblings-variable: ly:spanner? - In the music-function I added a new variable to specify the grob. These give the advantage to define only one music-function. Of course there is need to specify which grob should be applied. But now it works for all curves: Slur PhrasingSlur Tie RepeatTie LaissezVibrerTie I didn't test it very widly, but what do you think? Best, Harm Oops, forgot to delete the wrong version-number.. Please switch to \version 2.15.36 or higher. -Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi Harm,
On Thu, May 10, 2012 at 6:00 PM, Thomas Morley
thomasmorle...@googlemail.com wrote:
2012/5/11 Thomas Morley thomasmorle...@googlemail.com:
Hi David,
I thought a while about your function.
I'd like to suggest some changes. In the attached file you can see:
- Elimination of `function' as argument of shape-curve and introducing
it as local variable.
I like this! I had thought of looking up the callback (as an alternative
to passing it in), but hadn't found a way to do it. Nice!
- A new condition added in shape-curve at the siblings-variable:
ly:spanner?
Right--otherwise overriding LaissezVibrerTie won't work.
- In the music-function I added a new variable to specify the grob.
Aha--I didn't realize you could drop the # in the latest versions. I like
this too. Of course, if you want to stick with shapeSlur (and its ilk) you
can define it like this:
shapeSlur =
#(define-music-function (parser location offsets) (list?)
#{
\once \override Slur #'control-points = #(shape-curve offsets location)
#})
These give the advantage to define only one music-function.
Of course there is need to specify which grob should be applied.
But now it works for all curves:
Slur
PhrasingSlur
Tie
RepeatTie
LaissezVibrerTie
I didn't test it very widly, but what do you think?
I like it all.
Oops, forgot to delete the wrong version-number..
Please switch to \version 2.15.36 or higher.
I don't have 2.14.2 up to test, but this all should work there provided you
add the # before the string?
So:
\shape #Slur #'( ...
Thanks so much!
Best,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi David, 2012/5/11 David Nalesnik david.nales...@gmail.com: I don't have 2.14.2 up to test, but this all should work there provided you add the # before the string? So: \shape #Slur #'( ... I tested what's needed to make it work with 2.14.2 (therefor the 2.14.2-version-number in the file). Well, you can boil down the main-function quite easily, but `ly:input-warning' is not part of 2.14. Deleting the whole warning-part would mean a considerable loss of functionality. And I didn't think about an alternative for 2.14.2, hoping for 2.16 coming soon. Thanks so much! Best, David You're welcome. -Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi David, now I tested your new function. OK, I didn't test more than the sources you provided, but I think they give all the necessary combinations. So my conclusion is: This is awesome! I won't ever live without this (as long as LilyPond is concerned) anymore - as long as it won't get broken by new versions. One idea to make it even more comfortable and generic to use would be not to hard-code the color within the function. If one could somehow set the color outside the function one could personalize it to ones needs. As this is kind of a library thing, I think it isn't necessary to make this settable at runtime through the function call. Maybe one could define a variable for the color above the function, setting #black as default. Then anybody can easily see how to adapt it even if she/he doesn't understand the function itself. Ah, I just realized that this way one could still set the color in the music source by redefininge the variable ... I would be happy about this enhancement. But I really have to admit that this is quite low priority because the function is already extremely helpful. Best and thanks again Urs Am 09.05.2012 01:49, schrieb David Nalesnik: Hi Urs, Hi David, as promised I tried out your updated function(s). Well, you can't call this a complete test suite, but it seems to work perfectly. Many thanks. Attached is a version showing that it also/still works with phrasingSlurs. I find the warnings very useful. I assume it isn't possible to find out and display the 'real' place in the source where the problem comes from? As it is, I only know that there is a changed curve that doesn't work anymore, but don't know where it is (which can of course be difficult to pin down in larger pieces. If it isn't possible to identify the calling line in the source code, would it be possible to mark the respective curve red? This way one could easily spot the problematic grob. You can do either, or both. The attached file will display a warning which includes the input location and (if you uncomment the relevant lines in shape-curve) print the curves in red. That a wrong number of pairs gives strange results is OK. That way one is gently pointed towards malformed input ;-) +1 So it works like a charm now :-) If you could still add the colour or line number feature - or tell me that you won't or can't do it - I could make a useable and distributably version of the file - maybe as a package together with displayControlPoints (see other mail in the other thread). Sure, please do! In the meantime, I'll keep tinkering with this and I'll send along any improvements. Thank you very much for your comments! Best, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi Urs, On Wed, May 9, 2012 at 10:13 AM, Urs Liska li...@ursliska.de wrote: Hi David, now I tested your new function. OK, I didn't test more than the sources you provided, but I think they give all the necessary combinations. So my conclusion is: This is awesome! I won't ever live without this (as long as LilyPond is concerned) anymore - as long as it won't get broken by new versions. Great! I'm very happy to hear this! One idea to make it even more comfortable and generic to use would be not to hard-code the color within the function. If one could somehow set the color outside the function one could personalize it to ones needs. As this is kind of a library thing, I think it isn't necessary to make this settable at runtime through the function call. Maybe one could define a variable for the color above the function, setting #black as default. Then anybody can easily see how to adapt it even if she/he doesn't understand the function itself. Ah, I just realized that this way one could still set the color in the music source by redefininge the variable ... I would be happy about this enhancement. But I really have to admit that this is quite low priority because the function is already extremely helpful. This isn't difficult to do. As you say, you could define a variable for color above the function. All you would need to do then is replace red with the name of the variable in the two places it occurs. In the attached file, I do this and give several ways of specifying the color you want. (Of course, it's the last definition that is actually used.) Best and thanks again Urs You're very welcome! Best, David shaping-curves03.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi Urs, Hi David, as promised I tried out your updated function(s). Well, you can't call this a complete test suite, but it seems to work perfectly. Many thanks. Attached is a version showing that it also/still works with phrasingSlurs. I find the warnings very useful. I assume it isn't possible to find out and display the 'real' place in the source where the problem comes from? As it is, I only know that there is a changed curve that doesn't work anymore, but don't know where it is (which can of course be difficult to pin down in larger pieces. If it isn't possible to identify the calling line in the source code, would it be possible to mark the respective curve red? This way one could easily spot the problematic grob. You can do either, or both. The attached file will display a warning which includes the input location and (if you uncomment the relevant lines in shape-curve) print the curves in red. That a wrong number of pairs gives strange results is OK. That way one is gently pointed towards malformed input ;-) +1 So it works like a charm now :-) If you could still add the colour or line number feature - or tell me that you won't or can't do it - I could make a useable and distributably version of the file - maybe as a package together with displayControlPoints (see other mail in the other thread). Sure, please do! In the meantime, I'll keep tinkering with this and I'll send along any improvements. Thank you very much for your comments! Best, David shaping-curves02.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi David, thanks for the new 'delivery'. I copied it to my project folder, but it's too late now here to investigate it (has to wait for tomorrow). I'm really looking forward to making all this available in a structured way (although it will surely take some time). Experience working with your function and the new options to visualize the control-points is so beautiful and such a tremenduous improvement in handling LilyPond ... Best Urs Am 09.05.2012 01:49, schrieb David Nalesnik: Hi Urs, Hi David, as promised I tried out your updated function(s). Well, you can't call this a complete test suite, but it seems to work perfectly. Many thanks. Attached is a version showing that it also/still works with phrasingSlurs. I find the warnings very useful. I assume it isn't possible to find out and display the 'real' place in the source where the problem comes from? As it is, I only know that there is a changed curve that doesn't work anymore, but don't know where it is (which can of course be difficult to pin down in larger pieces. If it isn't possible to identify the calling line in the source code, would it be possible to mark the respective curve red? This way one could easily spot the problematic grob. You can do either, or both. The attached file will display a warning which includes the input location and (if you uncomment the relevant lines in shape-curve) print the curves in red. That a wrong number of pairs gives strange results is OK. That way one is gently pointed towards malformed input ;-) +1 So it works like a charm now :-) If you could still add the colour or line number feature - or tell me that you won't or can't do it - I could make a useable and distributably version of the file - maybe as a package together with displayControlPoints (see other mail in the other thread). Sure, please do! In the meantime, I'll keep tinkering with this and I'll send along any improvements. Thank you very much for your comments! Best, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Am 29.04.2012 00:26, schrieb David Nalesnik: Hi Urs, On Fri, Apr 27, 2012 at 6:05 PM, Urs Liska li...@ursliska.de mailto:li...@ursliska.de wrote: Am 27.04.2012 19 tel:27.04.2012%2019:30, schrieb David Nalesnik: Hi Urs, On Fri, Apr 27, 2012 at 11:46 AM, Urs Liska li...@ursliska.de mailto: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 http://lsr.dsi.unimi.it/LSR/Item?id=639%29I 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
Re: is shapeSlur broken?
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
Re: is shapeSlur broken?
Hello Urs,
yes there was a syntax change:
you might try
shapeSlur = #(define-music-function (parser location offsets)(list?)
#{
\once \override Slur #'control-points = $(shape-slur offsets)
#})
Variables in musicfunctions now are available by there name without the
preceding $.
The $-sign now introduces a scheme-expression and returns the result
directly ... now here should be more explanation, that I am not able to
put in words right now ;-)
HTH
Cheers, Jan-Peter
On 27.04.2012 10:11, Urs Liska wrote:
Hi list,
the shapeSlur function from the LSR
(http://lsr.dsi.unimi.it/LSR/Snippet?id=777) doesn't seem to work
anymore (at least for me).
That's the 'entrance' function:
shapeSlur =
#(define-music-function (parser location offsets)
(list?)
#{
\once \override Slur #'control-points = #(shape-slur $offsets)
#})
When calling this function I get the error:
Fehler: GUILE signalisierte einen Fehler für den hier beginnenden
Ausdruck
\once \override Slur #'control-points = #
(shape-slur $offsets)
then
Warnung: Typprüfung für »control-points« gescheitert; Wert
»#unspecified« muss vom Typ »list« sein
and finally
Unbound variable: $offsets
From what I see I assume that this is due to some change in syntax at
some point (the last time I recall using this function was with 2.14.0).
But as you know I'm still quite lost with Scheme, so I can't neither
verify nor fix this, and so I'd be gracious for any advice. Of course
I can't be sure that this type check at the calling of the 'main'
function is all there is to it, but lilyPond doesn't even get to call
shape-slur ...
Best
Urs
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Jan-Peter Voigt jp.vo...@gmx.de writes:
Hello Urs,
yes there was a syntax change:
you might try
shapeSlur = #(define-music-function (parser location offsets)(list?)
#{
\once \override Slur #'control-points = $(shape-slur offsets)
#})
I would write #(shape-slur offsets) here: there is no need for an
immediate Scheme expression here (the point of $ over # is that the
syntactical function of the $ expression is determined by its expression
type, but here the syntactical function needed is Scheme anyway).
Variables in musicfunctions now are available by there name without
the preceding $.
The $-sign now introduces a scheme-expression and returns the result
directly ... now here should be more explanation, that I am not able
to put in words right now ;-)
$some-expression is equivalent to \name if you had written
name = #some-expression
some times earlier where an assignment is allowed. Actually, whenever
name is a valid LilyPond identifier name as well as a valid Scheme
identifier name, $name and \name are perfectly equivalent.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hello Jan-Peter,
thank you very much.
This seems to solve the problem. Maybe it's not perfectly robust, though.
The function now works when the number of lists exactly matches the
number of slur fragments. I'm not sure if this has been the case earlier
or if it had been a little bit more 'generous'.
For the project at hand I can live with that anyway.
Best ans many thanks
Urs
Am 27.04.2012 10:28, schrieb Jan-Peter Voigt:
Hello Urs,
yes there was a syntax change:
you might try
shapeSlur = #(define-music-function (parser location offsets)(list?)
#{
\once \override Slur #'control-points = $(shape-slur offsets)
#})
Variables in musicfunctions now are available by there name without
the preceding $.
The $-sign now introduces a scheme-expression and returns the result
directly ... now here should be more explanation, that I am not able
to put in words right now ;-)
HTH
Cheers, Jan-Peter
On 27.04.2012 10:11, Urs Liska wrote:
Hi list,
the shapeSlur function from the LSR
(http://lsr.dsi.unimi.it/LSR/Snippet?id=777) doesn't seem to work
anymore (at least for me).
That's the 'entrance' function:
shapeSlur =
#(define-music-function (parser location offsets)
(list?)
#{
\once \override Slur #'control-points = #(shape-slur $offsets)
#})
When calling this function I get the error:
Fehler: GUILE signalisierte einen Fehler für den hier beginnenden
Ausdruck
\once \override Slur #'control-points = #
(shape-slur $offsets)
then
Warnung: Typprüfung für »control-points« gescheitert; Wert
»#unspecified« muss vom Typ »list« sein
and finally
Unbound variable: $offsets
From what I see I assume that this is due to some change in syntax at
some point (the last time I recall using this function was with 2.14.0).
But as you know I'm still quite lost with Scheme, so I can't neither
verify nor fix this, and so I'd be gracious for any advice. Of course
I can't be sure that this type check at the calling of the 'main'
function is all there is to it, but lilyPond doesn't even get to call
shape-slur ...
Best
Urs
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hello David, I would write #(shape-slur offsets) here: there is no need for an immediate Scheme expression here (the point of $ over # is that the syntactical function of the $ expression is determined by its expression type, but here the syntactical function needed is Scheme anyway). thank you! Variables in musicfunctions now are available by there name without the preceding $. The $-sign now introduces a scheme-expression and returns the result directly ... now here should be more explanation, that I am not able to put in words right now ;-) $some-expression is equivalent to \name if you had written name = #some-expression some times earlier where an assignment is allowed. Actually, whenever name is a valid LilyPond identifier name as well as a valid Scheme identifier name, $name and \name are perfectly equivalent. Cheers, Jan-Peter ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi Urs, On Fri, Apr 27, 2012 at 4:23 AM, Urs Liska li...@ursliska.de wrote: Hello Jan-Peter, thank you very much. This seems to solve the problem. Maybe it's not perfectly robust, though. The function now works when the number of lists exactly matches the number of slur fragments. I'm not sure if this has been the case earlier or if it had been a little bit more 'generous'. For the project at hand I can live with that anyway. I've rewritten shape-slur so that you should be able to use lists of offsets which don't match with the number of slur fragments. I've tested it somewhat, but if you run into a problem, let me know. Here's the relevant part: #(define ((shape-slur offsets) grob) (let* ( ;; have we been split? (orig (ly:grob-original grob)) ;; if yes, get the split pieces (our siblings) (siblings (if (ly:grob? orig) (ly:spanner-broken-into orig) '() )) (total-found (length siblings))) (define (helper sibs offs) (if (and (eq? (car sibs) grob) (pair? offs)) ((alter-curve (car offs)) grob) (if (pair? offs) (helper (cdr sibs) (cdr offs)) ((alter-curve '()) grob (if (= total-found 2) (helper siblings offsets) ((alter-curve offsets) grob Hope this helps! David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
Hi Urs, On Fri, Apr 27, 2012 at 6:51 AM, David Nalesnik david.nales...@gmail.comwrote: Hi Urs, I've rewritten shape-slur so that you should be able to use lists of offsets which don't match with the number of slur fragments. I've tested it somewhat, but if you run into a problem, let me know. I noticed that you'll produce an error if you apply a list of lists to a slur which isn't broken (i.e., if a layout change results in a once-broken slur appearing on a single line). Here is a fix for that: #(define ((shape-slur offsets) grob) (let* ( ;; have we been split? (orig (ly:grob-original grob)) ;; if yes, get the split pieces (our siblings) (siblings (if (ly:grob? orig) (ly:spanner-broken-into orig) '() )) (total-found (length siblings))) (define (helper sibs offs) (if (and (eq? (car sibs) grob) (pair? offs)) ((alter-curve (car offs)) grob) (if (pair? offs) (helper (cdr sibs) (cdr offs)) ((alter-curve '()) grob (if (= total-found 2) (helper siblings offsets) (if (list? (car offsets)) ((alter-curve (car offsets)) grob) ((alter-curve offsets) grob) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
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 ... Best Urs Am 27.04.2012 15:22, schrieb David Nalesnik: Hi Urs, On Fri, Apr 27, 2012 at 6:51 AM, David Nalesnik david.nales...@gmail.com mailto:david.nales...@gmail.com wrote: Hi Urs, I've rewritten shape-slur so that you should be able to use lists of offsets which don't match with the number of slur fragments. I've tested it somewhat, but if you run into a problem, let me know. I noticed that you'll produce an error if you apply a list of lists to a slur which isn't broken (i.e., if a layout change results in a once-broken slur appearing on a single line). Here is a fix for that: #(define ((shape-slur offsets) grob) (let* ( ;; have we been split? (orig (ly:grob-original grob)) ;; if yes, get the split pieces (our siblings) (siblings (if (ly:grob? orig) (ly:spanner-broken-into orig) '() )) (total-found (length siblings))) (define (helper sibs offs) (if (and (eq? (car sibs) grob) (pair? offs)) ((alter-curve (car offs)) grob) (if (pair? offs) (helper (cdr sibs) (cdr offs)) ((alter-curve '()) grob (if (= total-found 2) (helper siblings offsets) (if (list? (car offsets)) ((alter-curve (car offsets)) grob) ((alter-curve offsets) grob) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
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! 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.) I could create a warning here, something like: slur is not broken anymore. 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)? Any thoughts? -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: is shapeSlur broken?
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
mailto: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
http://lsr.dsi.unimi.it/LSR/Item?id=639%29I 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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
%{
shapeXXX.ily
base include file with typographic tweaks
modifing the shapes of Bezier curved spanners.
Provided by Urs Liska (m...@ursliska.de)
Exported functions:
- shapeSlur
- shapePhrasingSlur
- shapeTie
This version works also with line broken curves
and modifies the shapes of the siblings individually
Usage: \shapeXXX (offsets) music
offset is a list of eight numbers indicating the x and y offsets
for the four control-points of the curve
for each part of a broken slur one can give a separate list.
An empty list means that the respective slur isn't altered
in contrast to overriding the control-points property
this function
