Observing selected scene

Mar 31, 2011 at 1:55pm

Observing selected scene

Trying to do something basic, but it confuses me. Observing the selected scene does give me a new id, but is not handled by the live.object when I ask for its name. This can be solved by including a deferlow, but that seems a little awkward. Moreover, many warnings occur: live.object: Live API is not initialized, use live.thisdevice to determine when initialization is complete. It appears something has changed, but I don’t really get what. Any advice?

– Pasted Max Patch, click to expand. –
#55988
Mar 31, 2011 at 5:05pm

Actually it is handed to the Live object (sort of) but it can’t do anything with it. When you have your Max device loaded right click on the title bar and use “Open Max window”. You won’t get the same window which you’d get when editing the device; this is the “runtime” window.

And its ideal for debugging your patches since many warning and/or error messages which won’t find their way into the main Max window will be shown here.

In your case: “live.object – Setting the id cannot be triggered by notifications“.

So it is receiving the id message yet cannot use it. The solution, as you mentioned yourself, is using deferlow. Its really not that awkward; it will only make sure that any code you put behind it is executed last.

To put it simple; it will (to a certain extend) protect you from loops. You know; your observer checks a dial and when it detects a change you let it trigger code which sets the value to something else. Resulting in the observer spotting a change which triggers another change and so on…

That is (to an extend) avoided by deferlow. It will simply make sure that any code you put behind it will be executed when all other parts of your patch have finished.

Proof of concept (added deferlow to your patch):

– Pasted Max Patch, click to expand. –

Oh, ps: although it looks cleaner you don’t really need the loadbang in there. The moment you use an argument with live.path it will send out the value as soon as the patch is loaded.

Its no big deal and using a loadbang has advantages (making your patch easier to read) but I figured I’d mention it nonetheless.

#201155
Aug 4, 2011 at 3:54am

HI – can I follow up with a newbie question?

1) For getting the name why would you use ‘get’ and not ‘observe’? is it because ‘get’ is less cpu intensive (as it doesn’t need to ‘listen’ for updates from the application, and it receives a bang anyway everytime the ‘selected_scene’ changes?)

2) is there a reason why you would first set the path to live_set view, then observe selected_scene, and then with the ID go a ‘get name’? Why not cut out one step and use the path of “live_set view selected_track” and go straight to a ‘get name’ after that?

I can see in my test patch that both give the same result (though I might be overlooking specific conditions) – I’m interested in the cleanest, but also most efficient programming as I want to use this for realtime performance control.

Thank you!

#201156
Aug 4, 2011 at 4:06pm

Although this isn’t my patch I guess I can comment in general..

1) Hoover the mouse over the left inlet (top left) of the live.object object. Or check the reference page.

live.object doesn’t know about observe. But speaking in general; if you only want to get the name of a device once its better to use get with live.object because that gets the name without doing anything else.

As you mentioned yourself; observe would get the name but continue to observe the property for any changes, which isn’t always desirable.

2) The “selected_track” path won’t give you the name of the scene, which I think is what the OP was after.

#201157

You must be logged in to reply to this topic.