How to get a list of all tracks in the set
Hi.
As a first step to building a device I decided to try and get Live to cough up a track list. So I created a patch like this:
What I expected was a consistent ID and an object containing children representing the tracks in my set. What I actually observe is a different ID each time I set the path and the following output:
print: info type tuple
print: info description tuple() -> an empty tuple tuple(sequence) -> tuple initialized from sequence's items If the argument is a tuple, the return value is the same object.
If I extend the path to a specific track, e.g. track 0, then I get the expected track information.
Can anyone tell me what I am doing wrong in attempting to enumerating the tracks in the set?
Thanks.
Matt
First; it helps to have the trigger object's bang output connected to the message object ;-)
ID's aren't static, only paths are. The moment something is changed within the liveset (devices or tracks added/(re)moved) then you risk the id's from changing. Also see the Live API reference for info on this.
Another detail which I'd suggest avoiding is using the live.path object with a parameter and sending it a message afterwards. This can influence the id assignment quite drastically as well.
In short: loaded with an argument live.path will assign and send out an id the very moment the patch gets loaded ("started"). So; in your case it'll start asking 'getinfo' from the Song class ('live_set') and assign it with an id, most likely id 1.
Next you click the button and you focus your attention to tracks (a child of the Song class). Thus it gets id 2.
So far the theory...
Where you're going wrong here is that you're pinpointing live.path to "live_set tracks". Check the LOM; 'tracks' is basically a child from Song (see here).
Asking that child for information gets you no where (as you've noticed yourself) since its basically (quote) "An empty tuple".
"getinfo" is a function (message) specific for a live.object and is only used to get information about the current object (see here).
Edit: You'd want to use getinfo to learn more about a certain object. For example, to know what its children are, what properties it has and what functions it supports. But all of that is specific for live.object, and not what you want.
You don't want to know what 'live_set tracks' is (an empty tuplet), you want to know what it represents ('contains').
Back to the LOM (the link above). If you look closely at the Song class again you'll see that you can get or observe tracks. That is the right approach to get to know what it contains.
So:
And as a bonus (nah, kidding a bit) here's the same patch but this time making it a little easier to grok the output you got from it:
I think this may give you a good head start...
Hi there ShelLuser.
Many thanks for the lengthy reply, I do think you've addressed my main confusion. I'm still getting my sea legs with Max generally and with the LOM in particular. I'd obviously misunderstood the purpose of getinfo and was further confused by the fact that a path of "live_set tracks 0" seemed to return what I would have expected for a track, but "live_set tracks" did not.
I've also downloaded your(?) LOMnavigator device to try and understand the LOM better. As an aside, if it is yours, the archives on your site didn't work for me (they unpack to 0 length files on my Mac) but the device on maxforlive.com does work (albeit it seems an older version).
Thanks again.
Matt
Oh just as a further note, re-reading a part of your answer and thinking about my own thought processes.
What confused me is that the way that tracks is
basically (quote) "An empty tuple"
.
I guess what we are talking about here is the the metadata for the tracks object, i.e. there isn't any. Since I think I'd seen children in the info for other objects I'd assumed what I was looking at was an empty trackset which was nonsensical.
I'm also bound to say that I think the guys who came up with parts of the Live API should have thought a bit harder. When you "get tracks" why return "tracks id 2 id 5 id ..." instead of an array (2,5,...). Lots of this API just seems like it was designed to create busy work. But I digress. It's possible and that's the main thing.
Thanks again for your examples.
Matt