Ableton Forum

Hi all, I'm hanging out a thought on a limb here....

When I get an object from the LOM, I can pass its 'ID' and 'value' out of a live.observer, as a list.
When I try to pass the 'ID' via OSC (from within the Python script), I cannot get this magical 'ID'.
To try and explain better;

tc = self.song().tracks
tcLocalPacker = []
tcLocalPacker.append(tc[0])
self.pObsObj.value = ['TrackZeroID', tcLocalPacker]
# (pObsObj is an object observed by a live.observer)
self.pObsObj.receive_value(['TrackZeroID', tcLocalPacker])

This works and sends the message out of the live.observer..... TrackZeroID id 1
So, if a new track were inserted at track 0, then
tcLocalPacker.append(tc[1]) will yield 'id 1'

.....however, moving over to OSC:

tcOscPacker = OSC.OSCMessage('/TrackZeroID')
tcOscPacker.append(tc[0])
self.oscEndpoint.sendMessage(tcOscPacker)

This sends the message via OSC, but sends only....... /TrackZeroID

I have tried
tcOscPacker.append(id(tc[0]))

This sends the message via OSC, as....... /TrackZeroID 504968850 (or something similar)
This unique number would be useable, if only it was persistent over set changes, as the live.observer method is.
With each change to the set, the ID changes.

I'm no python expert, but I have looked at weak referencing (which seems of no help) as a way of gleaning unique, persistent IDs.
Does anyone have any ideas on this, or how to access, in Python, the IDs as seen in M4L... or is this not possible?
I've thought of building a data structure based on 'what has changed and where' in the set, but this would be a huge task for me.

From the standpoint of the problem being caused by some other part of my code, for both M4L and OSC, the connection methods are working fine, no weirdness going on there, it's definitely a 'how do you get a pesky unique and persistent ID' situation!

Thanks for your time - I won't be holding my breath on this one!!!

Leigh

I always seem to be in a hurry when you're asking interesting questions like this....and now is no different. Here's the short of it (if I'm understanding you correctly):

Any Live object sent between Python and Max is converted by MxDCore into the unique id you're looking for (if you send 'id', your_object_ID from Max to Python, it gets converted into the actual referenced object in Python; conversely, and as you've noted, sending an object from Python to Max will convert the object to 'id', the_object's_ID_you_sent). The reason it's not happening with OSC is because you're not passing the object from Python to Max via MxDCore (which makes this translation). Unfortunately, I'm not aware of a way to get this ID tag via Python without invoking MxDCore, and its __init__ is called from Max anyway. I'm not sure if its class can be invoked from within a CS script and still provide any usefulness, since the essential hooks will be missing when calling it in this way (I've spent some time playing around with this a bit recently, but to no avail). If only there were a decompile of the MxDCore available.....<sigh>.

What I'd recommend doing is to reuse the ID you get from the observer, bounce it back to Python via another function, and THEN send your OSC message. You don't need to do it every time, just store the property somewhere when the Max object is first linked through MxDCore. Cumbersome, but that's probably the best you're gonna get at present. Let me know if you come up with something else.

a

Hi James,
Hey , thanks for your confirmation... it's a bit of a pain, because I wanted to be able to do something with persistent ids without necessitating the use of M4L (for other users).
I'm going to have a look at building a structure that watches changes and builds a set of persistent ids.... I don't think this will be too difficult on a simple track / device basis, but once you start adding various depths of chains/return chains.... well, we'll see.
Yes, I'd love to see inside MxDCore too -it's a pity that whoever was kind enough to decompile the _framework docs didn't do those as well. I have 'decompyler', but it's not interested in decompiling the Ableton scripts as it says they are not python 2.7......

btw - thanks again for those pointers a while back. I'm pretty much finished now with my cue recall system, all bar cleaning up the gui to be as useful as possible. I'll keep you posted on that.
Cheers,
Leigh