This is a compilation of extracts from a discussion on the devel-list, under the (Spatialization namespace proposal) thread.

Nils :

Finally I propose a new optional argument: starttime. I think this is very useful for highly dynamic cues, when you just want to trigger an entire event, and then the scene is going to develop by itself

/Spat/Src/*/a+ 45 start 2000 ramp 5000 start azimutal rotation of all Sound Sources by 45 degree within 5 seconds after 3 seconds of arrival of this message
/Spat/Src/*/z- 10 ramp 10000 lifting up all sources by 10 unit steps within 10 seconds immediately

Another advantage of the starttime argument is that you could send messages in advance e.g. if you already know that at that real execution-time there is much traffic on that OSC-port you could send it in advance and just relax.
For the future I was also thinking about sending the starttime argument as a timecode (e.g. MTC or SMPTE) if there is the application for that accuracy, but for know I'll leave it like that :)

Trond :

This would either have to be implemented as part of the jmod.cuelist module, being a part of the syntax for cuelist scripts (in which case the osc message would be transmitted when it is about to be executed anyway), or by extending the current ramplib.

I'll make a note of this in terms of the discussion on ramplibs, but personally I am not sure what i fell about it. Another option would be to extend the current ramp syntax so that several ramps could be specified in a row, kind of like break-point functions:

/a 20. ramp 3000 10. ramp 2000. 3000 ramp 5000

But I am very unsure about this: I see it conflicting with a desire to keep the osc-messages and cuelist scripts easily readable. I also think that it raises some principal questions of what philosophy we want to have concerning real-time media, and how (and to what extent) modules are to be conceived as modules for work in real time.

Pascal :

I think I agree with Trond that this would make OSC-messages really hard to read... and anyway, this is already feasible with the actual syntax of jmod.cuelist... except it sends the message at the desired time (instead of what Nils wishes, but I don't think that's a very big deal...)

Nils :

Another advantage of the starttime argument is that you could send messages in advance e.g. if you already know that at that real execution-time there is much traffic on that OSC-port you could send itin advance and just relax.

Pascal :

At the contrary, I think there are more risks that there will be more traffic when the cue is sent than some time after (in my experience at least, things have always happened this way..) so my personal opinion is that we shouldn't go this way at all...

Tim :

I'll just chime in to say that this presents a *lot* of scenarios that would need to be thought through. For example: 'pausing' the cuelist, having different master clocks, wanting to take snapshot of system state to synchronize with another computer, etc.

List of cases :