lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Command Alises


From: p
Subject: Re: Command Alises
Date: Wed, 08 Feb 2023 09:18:18 +0100

Valentin, thanks for the email below. It's very useful indeed.

Not only it clarifies the syntax of pass by copy and by value but also how to interact with the underlying scheme and how to create lilypond code blocks.

It was really useful. I am excited to play a bit more with the underlying scheme layer and see what I can create.

Paulo Matos

On 2023-02-07 14:06, Valentin Petzel wrote:
Hello Paolo,

This is slightly OT, but there are other ways to alias things. \... is used in Lilypond either for evaluating a function, accessing some scheme object or evaluating some reserved parser keywords (such as \override). sustainOn is in
fact a music object (not a function).

Now, when name is a function then \name ... will evaluate this function, and \name (leaving out the arguments) will cause an issue. If name is bound to
some music object then \name will return a copy of this object.

But you can directly access the scheme bindings using #name. So in your case
you can do

pdown = #sustainOn

Doing this does *not* create a copy but will reference the same music object,
which might be more what we expect from an alias. We can see this here
(replacing sustain by \cresc, because sustain is a bit boring):

cA = \cresc
cB = #cresc

#(display (eq? cA cresc))
#(newline)
#(display (eq? cB cresc))
#(newline)

{
  1\cresc 1\!
  1\cA 1\!
  1\cB 1\!
}

#(ly:music-set-property! cresc 'direction UP)

{
  1\cresc 1\!
  1\cA 1\!
  1\cB 1\!
}

From the output we see that cA (\cresc) is not the same object as #cresc, but cB (#cresc) is the same object as cresc. Further we see if we then change the object bound to cresc (in this case by setting the direction property to UP) this will affect cB, but not cA (as cA was copied before we modified the
underlying object).

Since we are only creating a binding to an existing thing this will also
easily allow aliasing of functions:

tp = #tuplet

{ \tp 3/2 { c' d' e' } }

So this syntax does have the advantage of being usable for both objects and
functions.

The other options would be to wrap the function:

tp =
#(define-music-function (frac mus) (fraction? ly:music?)
   (tuplet frac mus))

{ \tp 3/2 { c' d' e' } }

This way means that we alias not to the value of a binding, but to the binding itself, as the binding is resolved only when the function is called. So doing
this:

tpA = #tuplet
tpB =
#(define-music-function (frac mus) (fraction? ly:music?)
   (tuplet frac mus))

{ \tpA 3/2 { c' d' e' } \tpB 3/2 { c' d' e' } }

tuplet =
#(define-music-function (frac mus) (fraction? ly:music?)
   mus)

{ \tpA 3/2 { c' d' e' } \tpB 3/2 { c' d' e' } }

We see that tpA will not be affected by binding the name tuplet to a different
value (as it points to the function that was bound to tuplet before
rebinding), but tpB will be affected. Similarly if we do not have a function
but some music object we can also wrap this in a 0-argument function to
actually alias the name (instead of the value):

pdown =
#(define-music-function () () #{ \sustainOn #})

Even if in this case (and in fact in most cases) this does not really make any
difference I think it is useful to be aware of these differences.

Cheers,
Valentin


Am Dienstag, 7. Februar 2023, 12:45:34 CET schrieb p@ocmatos.com:
On 2023-02-03 16:46, Aaron Hill wrote:
> Well, and those names are non-sensical.  \sustainOn implies depressing
> the pedal.
>
> %%%%
> \version "2.22.0"
>
> pdown = -\sustainOn
> pup = -\sustainOff
> pupdown = -\sustainOff \sustainOn
>
> { b'4\pdown 2 4\pupdown 2. 4\pup }
> %%%%
>
> That probably makes more sense.

Right, I confused the names, thanks for the help. One further question,
why the need to prefix the commands with a - ? Does it start some sort
of command mode?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]