matheus leston

I'm developing a Max For Live device do integrate my Ableton setup with a Max patch in order to play video by launching clips. The device is really simple: it reads the name of the playing clip of the channel and send it thought udpsend to 127.0.0.1. The Max patch receives the name and triggers the appropriate video file.

But for this purpose, timing is essential and I'm getting a lot of sync issues. I thought it had something to do with udpsend, but the problem is with live.observer. Here is the test I did:

There is a lot of inconsistency and delay at the launch of the clip. Is there anything that can be done to improve it or is it the way this API works, with no workaround?

live-observer-delay

If there is no workaround, is there a better way to send complex messages from Ableton to Max?

The playing_slot update is linked to the quantise of Ableton obv - are you sure it's not just waiting to hit your quant setting before launching the clip? I get no delays in the sending of this message...

> I get no delays in the sending of this message...

How did you prove this? In my experience the timing of Live API is generally not accurate.

leehu, it doesn't seems to be an issue of the quantising settings. the message is sent some milliseconds after the beginning of the clip. by turning the metronome on, I can clearly hear that it is off sync. also, the delay is not the same everytime, it drifts.

broc, that's what I was afraid of. by using another method, with custom clip automations sent to max, the result was spot on, perfectly on time. the Live API seems to have some sync issues. and that's a shame: reading the name of the clip and playing an video file with the same name was an elegant and very practical solution, but I'm afraid it will not work. sync is essential.

broc - sorry, i should have been more specific - I've got no noticable delays in the sending of this message, i.e. none of my code has an issue, maybe if it a few ms off, but i'm not doing anything critical to that point. All of my callback code is also in js rather than observers - not sure if this would make any difference - when i get a few minutes I'll write a test to see if the observer reports at the same time as the js, or maybe they're both delayed...

As I understand it, the Live API runs on low-priority threads (for technical reasons) and thus introduces unpredictable latency. This behavior has been discussed repeatedly on the forums, but unfortunately it's not mentioned anywhere in the official documentation.

It's a good thing to know, I might build some new notification system into my API then rather than rely on this for users that need perfect timing

This behavior has been discussed repeatedly on the forums, but unfortunately it’s not mentioned anywhere in the official documentation.

https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/

I guess if it needs to happen on the one, don't do it with LiveAPI.

However, there's a lot about it here: https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/

I guess if it needs to happen on the one, don't do it with LiveAPI.


live.observer - delay?