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:
----------begin_max5_patcher---------- 635.3ocyV1sbhCBEG+5jmBlb4NtNP9Rcua2Wic5jASXU5DgLAzU2N0m8ENjX 0Zr0lFc5ER7bfb3+4W3.7juWvb4VlJ.8CzuQddO464AtrN7Zr8BVQ2lWRUvv BVwTJ5BVvHWeZ1VM3mz54ORgVw+Gy5kDNF23thpyWxEKxpY4Z2DFkDa5FQhl XeDENNwXLcLF8Py6HVuhKJYZXlCewobst0KowKu.Tgb9ieO9XkHnq.kD7yZN srsGW.z6pXNkDDfdv1yy991lQWIKDr+ZlvyPw21+wYQ3D.BgD.IyRAC7mlEy 5AKT7EBS2CIQx2kWx1iRw3dSFxDh8Q5zAhLD7WCzPKT06QXzjDSCt+EQN7L8 cvSRm3ItC7D1e7L53+A+FRfUx2vFa.wRjdIWkUv1vyYnbpPJ34zxrJZMSn6D j32BjwjH.jybsNiKtaDoSPFcNHStLGQ+RVVb4sjtYvSNWwp2vpQUkzcVHnJk 5Ltnfs8iisl0ewNdkl71Xq6xyvywVzmBaGlbEcCqHyDPidynZcMe9Zs6.OuC jyKHqhUq3JMSjCwAC9AjOPfupb8BiV22i0kPIMA1E.kDMP7Mru78rZ7gb4ok RbQugTzvxHxsgQfpLUhhWewKHur9OEbJ45571P2bnN5kbqfozbAUykhiFi46 KhbXLK4EELn6VFthWTI4BciDBmlZu8UXj6vDBbXxoVDLv3YD3ZZ3iwaAWQmW xJNT5b1pgqM0RNQ1cmZQuSpMbpI9J.s8fxiFzsTNQWgbhuap4UId2xY1c6ak 89bWkbtSz4JqQ6iZbafPqp1XO0xERPHl8XeTVaMSGAlbgyDhXPs4pRsiepuM ZO6+ebebBYI -----------end_max5_patcher-----------
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?
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.
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.