miguelvb

i have done a m4L device and i would need that it knows the track where it is situated and like this be able to call live.observer in the correct live.path to monitor the clips in the track. Do not want to do it for all the live set, but only for that specific track, where the device is.

And is it possible to monitor a change in status of a clip in any track, via live.observer? and get the track and slot of the clip that changed?? i used to do that via liveOSC and was very useful....

So this is my problem:
i have done a m4L device and i would need that it knows the track where it is situated and like this be able to call live.observer in the correct live.path to monitor the clips in the track. Do not want to do it for all the live set, but only for that specific track, where the device is. 

can-a-m4l-device-know-the-track-it-is-on

Use the canonical_parent property. This property will always point to the parent (within the live.path) of an object. So in the case of a device (say: live_set tracks 1 device 0) this will point back to the track its on.

When you use the "this_device" root path you're home free. SO, feed this into a live.path: "path this_device canonical_parent".

As to your second question; What kind of status change are you referring to here?

It is not possible to use an individual object which monitors everything (all clips) at the same time. But there are ways to come across this. For example; suppose your status change is a clip playing or not. For that you could check for a change in the global transport (which is always running when a clip plays) and then go over the individual tracks.

have a look at this device here, which includes track monitoring for the moment.

http://www.maxforlive.com/library/device.php?id=553

still looking for the scene and clip monitoring, if you have done that before, please let me know!

have a look at this device here, which includes track monitoring for the moment.
http://www.maxforlive.com/library/device.php?id=553

still looking for the scene and clip monitoring, if you have done that before, please let me know!


thank you for the replays. Yes, that is the think to do:

use canonical_parent. i could use it and access the track. Thank you.

To monitor the clips in the track or whatever clip status, i use liveOSC, which is sending messages /live/clip/info T C S, with T=track of the clip, C clip index, S=status, each time there is a change in status... so that is easy to route for ALL the clips in the live set. Also via OSC you can monitor anything, almost. But with the live API you do not need osc communication, and it is more powerfull, seems to me.

thank you for the replays. Yes, that is the think to do:
use canonical_parent. i could use it and access the track. Thank you. 

To monitor the clips in the track or whatever clip status, i use liveOSC, which is sending messages /live/clip/info T C S,  with T=track of the clip, C clip index, S=status, each time there is a change in status... so that is easy to route for ALL the clips in the live set. Also via OSC you can monitor anything, almost. But with the live API you do not need osc communication, and it is more powerfull, seems to me.


Any ideas on tracking the path of a device without manually reloading?

This_device only works when called. It doesn't update when the device is actually moved. Not sure if this is a bug, but I assumed the middle outlet of live.path would at least send the ID out again.

The ID would be the same, but the path would have changed.

The only way I see around it is by monitoring all the tracks to see if any of the device orders changed. But if the device is moved within a Rack, you cant see it. And at that point it gets ridiculous to monitor everything.

Perhaps easier would be to just Metro the live.path. But I feel like I must be overlooking something. Surely the live.path in a device must know its actual path changed?

Any ideas on tracking the path of a device without manually reloading?
This_device only works when called. It doesn't update when the device is actually moved. Not sure if this is a bug, but I assumed the middle outlet of live.path would at least send the ID out again.
The ID would be the same, but the path would have changed.

Perhaps easier would be to just Metro the live.path. But I feel like I must be overlooking something. Surely the live.path in a device must know its actual path changed?


As I understand the LOM, objects generally don't "know" their current path or id. If needed, it can/must be retrieved from the actual configuration. And to register any changes automatically, the retrieval must be repeated in an appropriate time interval, basically the same as live.observer works in some cases.

As soon as you have a live.object (which you're basically only feeding the id of an object) it can then immediately determine its path again by using the 'getpath' message. Unfortunately this procedure sometimes fails whenever you're dealing with an object which can have multiple paths.

For example; the DeviceParameter class. It can be reached as 'live_set tracks 0 devices 0 parameters 0', however this is also valid: 'live_set tracks 0 mixer_device volume'.

If you try 'getpath' on a live.object which was following the latter object things get nasty.

@Bjorn: What exactly do you mean with "without reloading" ? I assume you meant without reloading the device, or did you mean without 'reloading' or 'reusing' already existing objects ?

I once wrote a patch which is fully aware of its location and can detect movement to another track. So you move it across devices on the same track and nothing happens, you put it onto another track and it spots this.

The "reload" or basically re-init is simply done by re-initializing the whole device again. And because I'm using the this_device path it will pick up its new location without any issues.

DO keep in mind that if you're going to trigger stuff based on a live.observer you'll probably need 'deferlow'.

@Bjorn: What exactly do you mean with "without reloading" ?  I assume you meant without reloading the device, or did you mean without 'reloading' or 'reusing' already existing objects ?

DO keep in mind that if you're going to trigger stuff based on a live.observer you'll probably need 'deferlow'.


"Without reloading" meant "Automatically". Not polling the object or having to press a refresh button.

How do you actually make a device reinitialize itself once its moved? Technically I would just need the live.path reinitialized, but I'm curious nonetheless.

Well, then that's basically what my device does indeed. That's to say; it doesn't poll on its own but merely uses a live.observer to check for any changes in the number of devices on the track it currently resides.

And well guessed; my patch starts through a loadbang which triggers 2 message objects to init the separate paths (this_device and this_device canonical_parent). When a change has been detected it simply bangs the trigger between the loadbang and the message objects. Simple but effective :)

And well guessed; my patch starts through a loadbang which triggers 2 message objects to init the separate paths (this_device and this_device canonical_parent). When a change has been detected it simply bangs the trigger between the loadbang and the message objects.  Simple but effective :)


Ah yes. But if the device is moved around inside a Rack chain, you don't get the update. Because the device list for the track remains the same.

can a m4l device know the track it is on ????????!!!!