Flaming Hakama by Elaine <ela...@flaminghakama.com> writes:
> David,
>
> On Mon, Jun 14, 2021 at 6:46 PM David Kastrup <d...@gnu.org> wrote:
>
>>
>> You saw the followup?
>
>
> Well, it seems I missed the follow up.
> Glad to see the functional approach.
>
>
>> The one with
>>
>> tempoChange =
>> #(define-music-function (interval endscale thenscale music)
>> (ly:duration? scale? (scale? 1) ly:music?)
>> "Make a gradual tempo change over @var{music}, essentially changing
>> speed after
>> every duration of @var{interval}, approaching a factor of speed of
>> @var{endscale}
>> compared to the start. Afterwards, tempo is switched to @var{endscale} of
>> the
>> original speed (default 1). If @var{endscale} is 0, the speed reached at
>> the
>> end is just maintained and can be overriden with an explicit @samp{\\tempo}
>> command if required."
>> (define (scaletempo oldscale newscale)
>> (make-apply-context
>> (lambda (ctx)
>> (set! (ly:context-property ctx 'tempoWholesPerMinute)
>> (ly:moment-mul (ly:context-property ctx 'tempoWholesPerMinute)
>> (ly:make-moment (/ newscale oldscale)))))))
>>
>> (let* ((muslen (ly:moment-main (ly:music-length music)))
>> (intlen (ly:moment-main (ly:duration-length interval)))
>> (steps (/ muslen intlen))
>> (endfactor (scale->factor endscale))
>> (thenfactor (scale->factor thenscale)))
>> (make-simultaneous-music
>> (list music
>> (context-spec-music
>> (make-sequential-music
>> (let loop ((rsteplst (iota (1+ steps) endfactor (/ (- 1
>> endfactor) steps)))
>> (res (if (positive? thenfactor)
>> (list (scaletempo endfactor thenfactor))
>> (list))))
>> (if (null? (cdr rsteplst))
>> res
>> (loop (cdr rsteplst)
>> (cons* (scaletempo (cadr rsteplst) (car
>> rsteplst))
>> (make-skip-music (ly:make-duration 0 0
>> intlen))
>> res)))))
>> 'Score)))))
>>
>> in it?
>>
>> --
>> David Kastrup
>>
>
>
> Things I would suggest to consider:
>
> Since this is presumably making several tempo changes in succession, I
> think that singular "tempoChange" is a bit misleading. Isn't \tempo
> already a tempo change? I would suggest "tempoTransition".
A ritardando is not a transition since it ends with the same tempo it
started with. At any rate, finding a good name is the least of my
worries...
> Some parts of this usage are a bit confusing. If I am slowing from 4=104
> to 4=92, as a user of this function, I am supposed to do the math and enter
> whatever the ratio 92/104 is?
You can just enter 92/104 as the ratio. That doesn't seem too
complicated. Changing from 4=104 to 4.=91 would be more tricky, but
then that seems kind of unusual for a gradual change.
> (Or, I have to write a scheme expression to do the calculation)?
92/104 can be entered as-is and is not much of an expression.
> Seems like it would be easier and clearer to just specify the
> resulting tempo, and let the function do the math to figure out the
> ratio.
That would mean that you cannot use the function as a building block for
"ritardando" since the function would not know what to start with.
> It would be helpful to document the variable "thenscale". Perhaps you
> used "endscale" instead of "thenscale" in some places in the comments?
The last two instances of @var{endscale} are wrong and need to be
@var{thenscale}.
> I am not sure I understand the notion of fiddling with the final
> tempo.
Basic use cases are: revert to original tempo, switch to different
tempo, stick with the final tempo. The first case requires emitting a
\tempo event by the music function (since the music function is the only
one that would know the original tempo reliably), the other two cases
can be dealt with the same, but "switch to different tempo" requires
_no_ other tempo event than what the user says next to be emitted.
The user interface I picked might not really be a good one. Its main
justification was "does the job", but that might possibly be done in a
better way.
> In general, specifying a tempo is for the music that follows. So to
> specify a tempo change and then have to do something else to maintain
> that tempo seems like extra. I can see that if you are going back to
> a Tempo, such a feature might seem useful. But in those cases, aren't
> you also going (assuming you are doing both MIDI and PDF) going to add
> \tempo "a Tempo" anyway?
\tempo "a Tempo" does not access tempoWholesPerMinute and thus can be
emitted in parallel with a manipulation with that context property.
So there is some justification for some parts of the design. Whether
that justification is worth it or precludes better solutions is
certainly an open question: I was just at the moment getting something
done that I needed to get done.
--
David Kastrup
