changed:
-
This is a compilation of extracts from a discussion on the devel-list, under the (Spatialization namespace proposal) thread.<br>
<br>
<li><b>Nils</b> : <br></li>
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 <br>
<br>
/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<br>
/Spat/Src/*/z- 10 ramp 10000           lifting up all sources by 10 unit 
steps within 10 seconds immediately<br>
<br>
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.<br>
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 :)<br>
<br>
<li><b>Trond</b> : <br> </li>
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.<br>
<br>
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:<br>
<br>
/a 20. ramp 3000 10. ramp 2000. 3000 ramp 5000<br>
<br>
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.<br>
<br>
<li><b>Pascal</b> : <br></li>
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...)<br>
<li><b>Nils</b> : <br></li>
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.<br>
<li><b>Pascal</b> : <br></li>
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...<br>
<br>
<li><b>Tim</b> : <br></li>
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.<br>
<br>
<b>List of cases</b> :<br>