lilypond-user
[Top][All Lists]
Advanced

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

Re: 2.21 note definition change


From: David Kastrup
Subject: Re: 2.21 note definition change
Date: Wed, 24 Jun 2020 02:05:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Paul Scott <waterhorse@ultrasw.com> writes:

> On 6/23/20 4:01 PM, David Kastrup wrote:
>> Paul Scott <waterhorse@ultrasw.com> writes:
>>
>>> On 6/23/20 2:23 PM, David Kastrup wrote:
>>>> Paul Scott <waterhorse@ultrasw.com> writes:
>>>>
>>>>> The 1st argument for note is now a duration rather than a string.
>>>>>
>>>>> I had some scheme definitions which were variations on \tempo.
>>>>>
>>>>> I used (string?) for this value before.  What is the new scheme
>>>>> equivalent?  (duration?)
>>>> ly:duration?
>>> Thank you, David.
>>>
>>> I believe I had tried that.
>>>
>>> Here's my MWE which hopefully will show someone what dumb mistake I'm
>>> making:
>>>
>>> \version "2.21.2"
>>>
>>> #(define-markup-command (notetest layout props dur) (ly:duration?)
>>>    interpret-markup layout props
>>>    (markup
>>>     #:note dur #up
>>>   ))
>>>
>>> {
>>>    \tempo \markup{ Allegro \notetest #4 }
>>>    c'1
>>> }
>>>
>>> Thank you,
>> Several.  Is there a reason you use the markup macro rather than
>> #{ \markup ... #} ?
> No.  Only that I had working code before
>> The latter can do the same but is more
>> straightforward to use when not familiar with Scheme syntax, and you
>> really make it appear like you aren't.
> Obviously not enough.  I used to make my living programming in many
> different languages.
>> You write interpret-markup ... instead of (interpret-markup ...) .  In
>> Scheme, every pair of paren conveys meaning.  They aren't syntactic
>> sugar which you can add or remove.
>
>
> Oops!  All my other code has (interpret-markup ... )
>
>> Then you write #up in Scheme.  # in Scheme introduces specially parsed
>> expressions, such as #(...) for literal vectors, or #{ ... #} for
>> embedded LilyPond or #t or #f for true and false boolean literals.
> Another dumb mistake.
>>
>> And both LilyPond and (Guile) Scheme are case sensitive: you cannot swap
>> up and UP.
>
> A bug or whatever.  I use lower case for #up and #down in \cueDuring
> and they work fine.  I have hundreds of working examples.  I am
> certainly clear on case sensitivity but this one seems to be an
> exception.

lilypond scheme-sandbox

shows that up and down are defined in the Scheme layer.  I have no idea
what code is responsible for that, but I'll take a look.

-- 
David Kastrup



reply via email to

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