Hey All, Is there a way to ensure that two patches will synch properly? Sometimes the simultaneous chucking of two heavy patches will cause a lag: one will be set back .5::T behind the other. I tried machine add for this, but ran into the same problem. Thanks, as always, & nice weekend, Tim
Hi Tim,
Is there a way to ensure that two patches will synch properly? Sometimes the simultaneous chucking of two heavy patches will cause a lag: one will be set back .5::T behind the other.
I'm not sure if this is what you are looking for, but here you go. Add this to the begining of your script : 1::second => dur t; t - (now % t) => now; That way the two scripts are supposed to start in sync at the next second. tom
[note: when I say "time step" below, I mean the next time "now" is explicitely set to]
1::second => dur t; t - (now % t) => now;
That way the two scripts are supposed to start in sync at the next second.
wouldn't something like 1::second => now; be enough to ensure that all initialization is done before the next time step? Additionally, if now % t is near t (say e.g. t-1) the operation t - (now % t) => now; performs only a few steps in time, that is the difference between (now % t) and t. Which specific problems should be solved by your code above? In general I think (or thought) chuck always works strictly in sync, except if the time needed by all the operations for a time step is more than allowed by the next time step, which either means the computer is too slow or the operations should be reordered in a better way. Am I wrong with this assumption?
Harald; wouldn't something like
1::second => now;
be enough to ensure that all initialization is done before the next time step?
Not if real time passes between sending the file to the VM and its actual execution due to compilation, I think. In general I think (or thought) chuck always works strictly in sync,
except if the time needed by all the operations for a time step is more than allowed by the next time step, which either means the computer is too slow or the operations should be reordered in a better way. Am I wrong with this assumption?
Yes, that's all true. However I don;t think ChucK can compensate for factors like the time compilation takes and the like. Scheduling the code to start doing interesting things at some known time after it enters the VM like with the modulo trick mentioned or by using for example events is the safest way to guarantee sync. Alternately you can practice sending it to the VM on the beat, that's also fun but clearly not a option in all contexts. Yours, Kas.
participants (4)
-
Harald Gutsche -
Kassen -
Timothy Leonido -
Tomtom