Hi Aaron,
#(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.
Yes, of course you're right that your solution is way more flexible (and
that I was too optimistic about the possible scheme-expression forms
created by \tempo).
I think what triggered my feeling uncomfortable was just the slight
mismatch between the name of the predicate (tempo?) and the actual tests
it contained. Maybe some verbose thing like music-with-tempo-definition?
would make things clearer.
Lukas
