Sequencing clips timing trouble
Hi guys.
First topic here . I'm a totally noob on m4l developing ... so have patience and sorry .
I'm trying to make my first m4l patch , for fun.
It's a clip sequencer based on live.grid , it's an audio effect and has problems in timing.
I have irregular time on launching clips .
So , my procedure is this :
Transport => Metro => Counter => Grid => Fireclip
i also tried
Transport => Plugsync=> Counter => Grid => Fireclip
In all cases my clips play late or not in time .It's this latency ? bad counter?
thanks
How much “not in time” are we talking about? IIRC ”call fire” on a clip object is like pressing its button, so its subject to whatever clip launch quantization is set in the clip(s). So even if your metro or plugsync~ is giving you very tight timing if its trigger a few samples late it wouldn’t play until the clip’s quantization point. If that’s the case you might want to set the is_playing property to 1 rather than use “call fire”.
Thanks for the reply.
I understand what you mean. I don't want to use quantization, my quantization should be none. Quantization partially solves my time problems, but it's an alternative solution, which doesn't work every time. I tried your solution but it didn't work, my mistake , probably. I try to better explain my problem. My "not in time" is irregular and random appear. The first step is every time wrong and the execution is irregular : somtimes a clip doesnt fire , often fires late . When quantizing isn't enabled this problems multiply.
Ok. Maybe you can paste your patch file here to make debugging easier or see if there are any obvious mistakes. Otherwise it's just guesswork (and it's been a while since I tried doing anything with clip triggering).
Keep in mind that the Live API is not suitable for time-critical tasks because the events are executed at low priority (UI thread) inducing some unpredictable latency.
It's possible, but accurate timing can only be achieved with quantization, and the trigger must be sent "sufficiently early" (e.g. >50ms) due to latency.
PS.
In your metro '120 ticks' should be replaced by '@interval 120 ticks', otherwise the number will be considered as 120 ms.
So Broc I have to fire a clip (a quantized clip) before it really starts, right? Are there any best practices for scheduling clips? What should I do to fire a clip "before"? Should I have to start my counter before the transpor starts? How? Do I have to introduce a delay between the transport start event and what? Are there some code to copy and paste?
For example, with 1 bar quantisation a solution would be to delay the counter by (1 bar - 100ms) and thus start playing the clips at bar 2. The same method can be used with other quantisation values, but not smaller than the latency.
Ty Broc . I dont undersand how . Where I have to place the delay before or after counter starts? I want a 32 quantization, is it possible ?All this seem a workaround.
The delay must be inserted between metro and counter. Choose a small value (eg. 10ms) so that the clip will start reliably at the next quantisation point.
Quantisation 32 may be problematic. But you can still reduce the latency with modification of your patch. Just calculate the IDs of all clipslots when the device is loaded. Then at runtime each step triggers only the fire call and quantisation 32 should work without problems.