Sequencing clips timing trouble


    Jun 01 2020 | 8:43 pm
    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

    • Jun 02 2020 | 2:37 am
      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”.
    • Jun 02 2020 | 1:27 pm
      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.
    • Jun 02 2020 | 3:08 pm
      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).
    • Jun 02 2020 | 4:51 pm
      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.
    • Jun 03 2020 | 11:44 am
      Here's the patch
      Broc , so there's no chance to fire a clip through a grid ?
    • Jun 03 2020 | 4:50 pm
      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.
    • Jun 03 2020 | 9:23 pm
      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?
    • Jun 03 2020 | 11:45 pm
      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.
    • Jun 05 2020 | 5:49 pm
      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.
    • Jun 05 2020 | 6:53 pm
      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.