Re: 2.21 note definition change

[Paul Scott]

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.

> In LilyPond expressions, you'd write #UP here, with # escaping from
> LilyPond mode into Scheme mode, and UP being the Scheme expression in
> question.  If you are doing copy-and-paste from documentation, only
> LilyPond mode will work sensibly, so my recommendation of using
> #{ \markup ... #} here.
>
> Then you call \notetest #4 where 4 is a number, not a duration.  To get
> into LilyPond parsing mode for an argument of a markup function, one can
> use braces (I am not sure this feature will persist to 2.22 in this
> form, but 2.21 is a development version).  So you need to write { 4 }
> here in order to get a duration.  In a way, that is syntactic sugar for
> writing ##{ 4 #} but the latter looks uglier.

I had tried 4 ; { 4 } and #4 with the broken code.  I'm clear on the # now.

Thank you very much for all of that analysis!!

Paul