live.observer – delay?

Feb 28, 2013 at 9:33pm

live.observer – delay?

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:

– Pasted Max Patch, click to expand. –

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?

#66778
Feb 28, 2013 at 10:11pm

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

#240360
Mar 2, 2013 at 5:00am

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…

#240361
Mar 2, 2013 at 9:52am

> 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.

#240362
Mar 2, 2013 at 6:40pm

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.

#240363
Mar 3, 2013 at 7:20am

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…

#240364
Mar 3, 2013 at 10:53am

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.

#240365
Mar 3, 2013 at 11:21am

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

#240366
Sep 22, 2013 at 9:38pm

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

Yes, like many, many things…

However, there’s a lot about it here: http://cycling74.com/2004/09/09/event-priority-in-max-scheduler-vs-queue/

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

#265954

You must be logged in to reply to this topic.