M4L strange live.object behavior, need to delay 'get name' message
I'm having trouble with this subpatch:
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.
-A
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
@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.