|Subject:||Re: Scheme predicative types|
|Date:||Thu, 17 Sep 2020 12:18:35 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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.
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|