es_84

I did a little test patch to see the precision of Abletons (version 8.4.2) clocking. It simply measures from a note-on to the next, playing simply quarter notes into it. Now I know Ableton is having issues with beeing accurate in terms of midi, I just wanted to see what the numbers are. In an empty Live set the patch shows a very moderate and totally acceptable latency, a crowded set jumps between +-3 ms. So I wonder if it is not rather M4L having issues following Live´s clock. Or did I something wrong in my patch? I´d be very happy if somebody has a clue what´s actually going on here : ) 

Ableton_Clock_Check.amxd

Hi everybody,
I did a little test patch to see the precision of Abletons (version 8.4.2) clocking. It simply measures from a note-on to the next, playing simply quarter notes into it. Now I know Ableton is having issues with beeing accurate in terms of midi, I just wanted to see what the numbers are. In an empty Live set the patch shows a very moderate and totally acceptable latency, a crowded set jumps between +-3 ms. So I wonder if it is not rather M4L having issues following Live´s clock. Or did I something wrong in my patch? I´d be very happy if somebody has a clue what´s actually going on here : ) 




Hi everybody,
I did a little test patch to see the precision of Abletons (version 8.4.2) clocking. It simply measures from a note-on to the 

midi-clock-precision

- Are you using MIDI clock for syncing Live to an external clock?

- Did you run the test patch in edit or performance mode?

- Are you using MIDI clock for syncing Live to an external clock?
- How are the quarter notes generated?
- Did you run the test patch in edit or performance mode?


no there is no extra midi clock involved, just Live´s clock. The notes also came from Live. I did a short midi pattern internally in song mode and looped it every 4 bars or so. I did not think about possible differences in performance and edit mode indeed. I was running it in edit mode. Do you think that can distort the results?

Hey Broc!
no there is no extra midi clock involved, just Live´s clock. The notes also came from Live. I did a short midi pattern internally in song mode and looped it every 4 bars or so. I did not think about possible differences in performance and edit mode indeed. I was running it in edit mode. Do you think that can distort the results?


Yes, I think since edit mode runs in the Max environment (connected to Live) it may lead to less accurate timing than performance mode running directly in the Live environment.

I will try it again in performance mode in a free minute and let you know. Thanks for the advice!

FWIW, when I test on my late 2016 MacBook Pro running Mac OS 10.12.5 with Live 9.7.2 and Max 7.3.4 in 64-bit mode, using quarter notes at tempo 120 in Live, and I test with the Max timer object I get a rock solid 500. ms, whereas when I test with cpuclock it shows an unpredictable alternation between 499. ms and 500. ms with an occasional larger interval (say 511. ms or so) to make up for the preceding 499s. In both cases, the overall average is correct, and the behavior is the same whether the device is in Edit mode or not.

Now it would be interesting if a crowded Live set gives different results.

Thanks for the clarification.
Now it would be interesting if a crowded Live set gives different results.


i found it difficult to get m4l midi notes into live recorded onto its grid in total sync, as like when you click a midi note onto the grid its 'perfect', but 

like recording a midi clip, incoming midi from m4l, using quantised plugphasor to trigger midi notes, each note was slightly off, on a moderate crowded live set.

i found it difficult to get m4l midi notes into live recorded onto its grid in total sync, as like when you click a midi note onto the grid its 'perfect', but 
like recording a midi clip, incoming midi from m4l, using quantised plugphasor to trigger midi notes, each note was slightly off, on a moderate crowded live set.



I get pretty much the same results as Christopher mentioned. A live set packed with vsts and stuff just causes that change of max. + - 3ms instead of 1 ms and the jittering increased. If you assume that this happens in every track (plus we have to see that vst´s etc cause latency aswell) you get that squishy mix we all know so well from Live I assume. When it comes to punchy beats, Live is not the best option for sure. Now why does the timer give rock solid 500 ms? My conclusion would be, that all the timing objects in Max are bound to cpu threading and so is ableton itself. That means we are not getting "real world timings". Everything appears to be in sync, but 1 ms is not necessarily a "real" ms. The cpu clock object - as far as I understand it - is always in high priority and is not connected to the max msp timing scheduler. Therefore it gives you the correct numbers. Correct me if I´m wrong. 

I obeserved that inaccuracy of 1 ms aswell (499 - 500ms). Looks like that is related to how Max deals with values smaller then 1 ms. But still I have no clue what the cpu clock deviations really represent and how syncing in M4L is done.

I get pretty much the same results as Christopher mentioned. A live set packed with vsts and stuff just causes that change of max. + - 3ms instead of 1 ms and the jittering increased. If you assume that this happens in every track (plus we have to see that vst´s etc cause latency aswell) you get that squishy mix we all know so well from Live I assume. When it comes to punchy beats, Live is not the best option for sure. Now why does the timer give rock solid 500 ms? My conclusion would be, that all the timing objects in Max are bound to cpu threading and so is ableton itself. That means we are not getting "real world timings". Everything appears to be in sync,  but 1 ms is not necessarily a "real" ms. The cpu clock object - as far as I understand it - is always in high priority and is not connected to the max msp timing scheduler. Therefore it gives you the correct numbers. Correct me if I´m wrong. 
I obeserved that inaccuracy of 1 ms aswell (499 - 500ms). Looks like that is related to how Max deals with values smaller then 1 ms. But still I have no clue what the cpu clock deviations really represent and how syncing in M4L is done. 

Just did another test using a M4L device that triggers [click~] from quarter notes of a clip (see patch) on 2 identical tracks with phase inversion on the second track. It turns out that audio on the master is completely cancelled (-inf) meaning the tracks play in perfect (sample-accurate) sync.

Not sure if this is the right question to ask but, which clock would you say is the most reliable? Live or a Max standalone?

That´s an interesting approach : ) So the inaccurate results come from time-related objects in Max.

Midi Clock Precision