M4L strange live.object behavior, need to delay 'get name' message
I’m having trouble with this subpatch:
----------begin_max5_patcher---------- 701.3ocyWFsjZBCEF9Z7oHSt15jDfrPua6z9Bza6tSGDhtoERbj3V2ty9t2j CnEUzETFWuAmbHP9Oe42yI75HO7T8ZQIF8YzOPdduNxyCB4B3UO1CWjrNMOo DlFtPTVlLWfGWcOiXsAhKyPgaBNSqLkx+Jb2fRlPpCqVUHU4BC7hX+OndkYS TZi2fJo.dC36WJSxQeQmmsYAVjXReRpl+ykhTSk5o7P6Bg3T2Ue1jvw1PSHn GqejpEw7xBQ07w3s2RlAKid5u9TPL1E6sQibWFe4LI3CkIr3AfIzAFI9ejHI lN.DI7rPRptnPnLGfjuJdVlJPPdzFYXsSFZqjgbTxbBnbWfCGrfH2OwbX.oA UZl5jyI0Uh+Xe3Cx7LQdxK1kpOo8oMDo5b8xZyuKMHauPajO8BNUdEJEvR3g v4.KyzD07VsM7gjcFzTT9k6WXmCRBfRsw.Wi7c+IpCDY7Q9yDmOj0Wd.e+pL oF8sYyrxE88jze+.dyrxkJQpdkxreleYlt9YmtCbPrJSIIxQOagn9VBhGNfd ok107DEfHCig58JMW4pnQ.f30CNIXNpkZPaYMWX5MaF51V0rIfAEgpFz+9Vb 1.ZZxkOKlXugSiCFYZT+lLINJvmF3peGQi4jHnRdHIN58pl2QZx8gBXAcvo0 JM8OGZV8tw8ui9QyCeJzghEt4Zq8sivaQb0wP1+nGmQt.Ru0Tgbxc4imJwGI S51NBi0VR1LyfmB5Cr2G8.RxEe2zsTuZY5l0rtak0FtcwyDkFoJwH0plShry jdRlkITMwRgLagVpL0h.8XqvuqZx9QKcPS7qpln2dRJ7FTSNG6sll3cgSt5I 2ZZxdlHag7tqov.3nqz5OCr5n8tQWpX6zlp+0Ef9cQSzqql36recBN0iMUJE 5gPCip9rsXXyMDZueYpkzEBxt.BZG71n+Ebn0kO -----------end_max5_patcher-----------
When fed id’s from the inlet I have to include the delay or I get the name of the previsouly selected object, as if live.object doesn’t update fast enough. But if I send the id’s from the message boxes in the patch it works fine without the delay. What’s up with that?
The patch feeding the inlet starts with a udpreceive for OSC messages and has several live.object and .path operations prior to this subpatch. Down the line from this subpatch I have more .object and .path operations but there a delay doesn’t solve the problem anymore. It keeps giving the previous value.
I ‘ve found these posts on the ableton forum but it s still not clear to me what happens exactly. Anyone can explain?
Calls to the API are asynchronous, and cannot be relied upon to return like normal Max objects at high priority.
That is to say if we send a message to live.object at high priority we will not know when we are going to get the answer back, high priority messages are "too impatient to wait around" and you have fixed it by simulating low priority with the delay object.
Mouse interaction with the patch is at low priority, so you hit the message box, the messages goes through at low priority and waits around till the live.object comes back with the name, and it all works.
The answer is funnel everything through the defer object to get it to a lower priority.Put a defer between the inlet and the trigger.Now you can get rid of the delay object.
Thanks Andrew, that cleared it up for me!
Is this in the M4L documentation? I bet I won’t be the last one running into this issue.
Btw, I didn’t realize you’re pukunui on the Ableton forum…
How on earth are we supposed to work this stuff out? :O( am finding this (M4L) a very steep learning curve and I am no newcomer to progamming. it’s a bit demoralising.
@macrosructure: i agree, there is a lot of semi secret knowledge involved here. I hope some day someone will write the perfect guide to programing max for live which exposes all those things. hmmmmmm, maybe I should do it and create a NY-Times bestseller???
@robert: I see asynchronous interrogation of the Live API as a fairly big issue…? How to compensate for this is a good candidate for the first few tutorials surely….
Funny, I was having the same problem using OSC. Clicking in the Max Interface worked great, but triggering it through OSC was giving me strange results. Anyway, I don’t know how, but I was using the "uzi" object and there was something with defer in it. Using defer solved my problem too.