On 2020-09-17 1:14 am, Lukas-Fabian Moser wrote:
Hi Aaron,
The three forms
* \tempo 4 = 96
* \tempo Crazy 4 = 260-270
* \tempo "Sluggishly slow"
are hardcoded as variants into the parser. My guess is that this
might
be hard (or impossible) to accomplish in a music function.
You just need to be a little creative.
That's what I hoped would happen. :-) If I understand it correctly,
both the genius and the drawback of your solution lies in having the
user write an explicit "\tempo" in order to invoke the parser's
hard-wired way of dealing with the possible syntax variants, right?
That is correct. In this situation, though, it might be too much to ask
of the user.
%%%%
\version "2.20.0"
#(define (tempo? arg)
(and (ly:music? arg)
(not (null? (extract-typed-music arg 'tempo-change-event)))))
Maybe I'm overly cautious, but I'd prefer this to be more specific so
that it accepts only actual "\tempo ..."-constructs. For example:
#(use-modules (scm display-lily)) #(define (tempo? arg) (and
(ly:music? arg) (string-startswith (music->lily-string test)
"\\tempo")))
This is probably an awful waste of computing effort, but I liked it
better than checking for the kind-of special internal structure of a
music expression containing only a \tempo (namely, a sequential-music
containing both a TempoChangeEvent and a PropertySet specced to
context Score.)
Note that \tempo produces different music depending on whether or not
there is a tempo-unit and metronome-count specified. That is why I
wrote the code the way I did, to keep a consistent interface despite the
internal differences. It could also be possible someone would want to
reuse an existing music expression that sets a tempo but does other
things, so tightening down the interface as you suggest could be overly
restrictive.
The only addition I would recommend would be to add an informative
warning (or error) should the provided music contain more than one
\tempo command as that would be somewhat ambiguous.
-- Aaron Hill