Best way to store a remote~ connection between closing/opening set?

    May 13 2010 | 6:11 pm
    I just learned that there's no direct way to query the Live API to find devices in effect/instrument racks. However, if I discover the ID of a device param OUTSIDE of a rack and then drag the device INSIDE, I'm still able to remote~ control it which is good.
    Now, because that device param no longer has a valid LiveAPI path that I could store in a pattr object, I don't know how I can save the link I've created to the param seeing as how ID's aren't maintained when you close/open a Live set.
    Anyone have any suggestions? What is the general best practice for saving a remote~ connection to a device param across closing/opening of sets?

    • May 17 2010 | 8:53 am
      Hi adam.
      I don't think there is a way to do what you want.
      Gererally it's best (or the only way) to save the path, because IDs are given newly each time you open a live set. But I guess you know that.
    • May 18 2010 | 1:14 am
      There is no way to do it - Ids are dynamically generated in the order you access objects by path (and so are potentially unqiue to each patch instance).
      If you cant access an object by path, then there is no way to recall it. This also means you cant change track the path either to keep pattr store updated, for example, because the user moved the device from one track to another.
      The problem with accessing devices inside racks appears to be only one of live.path addressing capability as you have shown, so I guess its time for someone to start a feature request campaign for this ;)
      Devices definately NEED a devices child for rack devices IMHO - its a right pain that it doesnt appear to exist.
      I also think ableton/cycling need to provide a change-tracked and thread safe parameter store for live paths as well - yes you can do it in MAX, but getting it all working correct and tracking path changes with crashing horribly from threading issues is a bit of a mare (yes - seems it needs to be thread safe too - urgh!).