< Back to IRCAM Forum

Restricting $RT_TEMPO to a certain range

Antescofo
#1

Hi guys,

For an automatic accompaniment patch I’m trying to restrict the backing track to a certain tempo range, so that if the performer slows down or speeds up too far beyond the scored BPM, the accompaniment will hit a ceiling, forcing the performer to adapt.

I tried to achieve this behaviour using whenever and @tempo_var (see http://forumnet.ircam.fr/user-groups/antescofo/forum/topic/synchronization-strategies-examples/ )

BPM 140 @tempovar $midi_tempo(140, 1)

whenever ($RT_TEMPO) {
switch {
case $RT_TEMPO > 150:
$midi_tempo.tempo := 150 ; causes an error
print tempo larger than 150
case $RT_TEMPO < 130:
setvar $midi_tempo.tempo 130 ; same error
print tempo smaller than 130
default:
setvar $midi_tempo $RT_TEMPO ; no error, but not what we want (doesn’t control .tempo)
print new tempo is ($midi_tempo.tempo)
}
}

NOTE B1 1/2 measure1

group G2 @local @target[20] @sync $midi_tempo
{
0.0 mnote 36 95 @beat2ms(0.5)
…


… but that’s not what tempo_var actually does, it still uses the listening machine to set the tempo.

Even if this were to work, I would expect a problem: say the performer dips under 130BPM, then in order to catch up to the 130BPM accompaniment they would have to speed up, which would produce a higher $RT_TEMPO and lead to a vicious spiral. So this needs to be considered too…

It would be perfect if this was controllable by a simple Antescofo attribute. I noticed antescofo::bpmtolerance, which is undocumented – is this what I’m looking for?

#2

Hello Grieg.

For the syntax error: just use the “full form” of assignment, that is
let $midi_tempo.tempo := …
it will work. The problem is that the abbreviated form expression := expression may be ambiguous. So this abbreviated form is not allowed in this case.

Forget about the undocumented antescofo::bpmtolerance: it enables to change dynamically a ponderation parameter in the Large algorithm used to infer $RT_TEMPO. It cannot be used to limit the tempo variations.

There is a lot of discussions about what must be a tempo functions, its inputs and its properties. the @tempovar mechanism is a first attempt to provide basic mechanisms to build arbitrary tempo functions. Other proposals are considered. Let us know your specific requirements. It will help to devise a meaningfull and general approach.

#3

Great, thanks JL!

As I explained, my requirement would be to specify a limited variance of $RT_TEMPO around the scored BPM. It would be fantastic if this mechanism could also anticipate the “catch-up” phase that I described in my first post.

So we could define an antescofo::bpmvariance 0.1 for example, which would indicate that the listening machine is allowed to advance with at most 10% a faster/slower pace than the scored BPM. Or maybe have two parameters for the lower and upper bounds?

By the way, is there an internal variable that contains the current scored BPM?

#4

Actually I think I don’t need @tempovar after all, I can use a simple variable here and declare the accompaniment group as
group G2 @local @target[10] @tempo $midi_tempo

Seems to work fine. Now to address the “catch-up” phase…

#5

Score Tempo Internal Variable: Yes there is… $SCORE_TEMPO giving you at each instant of its evaluation the tempo constant in the music score of origin at that position. This is now documented in the Antescofo Guide Section 6.3 or http://support.ircam.fr/docs/Antescofo/AntescofoReference.pdf#section.6.3

Regarding your question on the ability to limit the variance of detected tempo or $RT_TEMPO variable: We have so far tested several scenarios on this and each had limitations in certain musical situation (that can easily occur in any score) during musical performances. If you need details, I can clarify more with examples. Basically there is no free lunch here since the correlation between physical time, musical time, performance errors in physical time, and performance errors in score musical times are totally non-linear and context dependent!

But it seems like you have found the real musical solution.

To summarize what you are doing for others: You copy $RT_TEMPO into another variable, do your own smoothings and clippings there (using a whenever on every tempo change); and then use that variable as the tempo for your Group/Loop/Curve etc.

#6

Just saw your reply Arshia, thanks for the pointers!

If you have time, I’d like to see an example. Of course I realize we’re talking about a compromise: if the musician goes outside the BPM limits, then that would induce a “performance error” in the accompaniment, which isn’t allowed to closely track the musician’s tempo… but in such a case, this “error” would be the desired behaviour. Do you also have a different kind of error in mind?

I haven’t yet been able to fully test my solution so far. I wonder if other people would find such a built-in feature useful, or if it’s more of a headache than it’s worth…