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.

But a lot depends on context here.

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.

Actually that is partly true..

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.

Hope this gives an idea…

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

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 :)