This means that you have an effect or process that by default accepts absolute-time values. But you want to express those time-values in relative inside the content of their message/action.
You have two options:
(1) Use Antescofo functions
Declare a function that converts Beats to Milli-seconds in your score and use that inside a message. For example, assuming that your patch receive is DelayTime that accepts a float in milli-seconds, you have something like this in your Antescofo score:
1.0 DelayTime @beat2ms(2.0)
where beat2ms is defined in the beginning of your score as follows:
@FUN_DEF beat2ms(X) {
1000X60.0/RT_TEMPO
}
What it does: The value @beat2ms(2.0) is left unevaluted until real-time performance and in the very last possible instance. And at that time, Antescofo uses the lastly recognized tempo (RT_TEMPO) to convert 2.0 to Milli-seconds following the defined Formula in the above definition.
Advantage: You don’t change your patch but you get to use relative values!
Disadvantage: Once the value is sent to the receive, it can not be changed! For example, if it’s the time for a line and during the ramp the tempo changes, it won’t adapt!
(2) Use Max Transport
Alternatively, and ONLY if the object in question allows, you can use Max’s Transport system (new since Max5). Refer to Max Tutorial on this and also check the PDF file in the distribution folder of Antescofo: Antescofo_HelpFiles/Docs/MaxAntescofo_DurationTable.pdf
Advantage: If patched correctly, you can send Antescofo real-time tempo outlet to Transport and enjoy reactivity event on Line~ and similar
Disadvantage: Very few objects in Max use the Transport System. And the timing expressivity is highly limited!
