About persistence of ids and ids validity
I'm working on a m4l device that controls parameters in the live set in a contextual way. I can store presets so one single dial would control a different parameter for each preset.
It's working great but I have two questions, the first is about reliability, the second is about ids "validity" :
I use parameter ids to store the target parameters. Is it reliable ? Once an id is "created", it will be stored in the live set forever and will never be changed ? (I want to avoid storing the path so I can reorder tracks)
Let's say you made a preset of a targeted param. But then you delete the track where the param resides and then save the live set. You've stored an id that no longer exist.
So you can have an "invalid id" error in live.object or live.remote. Is there any way to check if the id is still valid ?
Also, is there a possibility that this invalid id would be "taken" by another param in the future ? I can imagine it would lead to cumbersome situations if an invalid id remains stored but then it would suddenly get back to life and control an unwanted param.
I would appreciate some clarification about these questions !
Hi,
yes, persistent IDs are persistent over the life of the Live set, and are written into the document.
when you delete a track referenced by a
live.object(for instance), the object continues to refer to the 'dangling' ID. This is actually a good thing, since if you undo that deletion, the object continues to point to the correct element in the LOM. But you will get 'invalid ID' errors if you try to use that ID for something.
I was curious about your last question, so I tried it (I recommend that you do it, too -- check my work). In fact, IDs appear to be re-used if I, for instance: delete a track which has a volume fader assigned to 'id 4' (which is being referenced by a live.object, save and re-open (and get the invalid ID error), and then create a new audio track and map the live.object to it's volume fader. Also 'id 4', which answers that question, I think.
To determine whether an ID which is assigned to a live.objectis currently valid without re-sending it and getting an error, you can send getinfo : if live.object reports info No object, the ID is currently pointing to nothing (gettype can also be used, reporting type unknown). I don't think we offer (or have) a way to easily check whether an arbitrary ID refers to something, if it's not currently being used by live.object or live.observer& co. But it's an interesting request, and maybe something you (or we) should ask Ableton about.
Hope this helps to clear some of this up!
Thanks a lot for your answers and experiments.
That would be kind of nice if recreation of previous IDS was forbidden, don't you think ?
Also, regarding the "getinfo" method to know wether there is actually a link to a parameter or not, that leads me to another question, related to the latency of API calls :
If you make sure that the object is bound to something and then use the result to trigger another action, like setting the value for instance, the total latency will be increased, wouldn't it ? Or am I missing something regarding API latency with m4l (which is another interesting topic...) ?
Most API calls are synchronous and all run on the main thread, so latency, in the sense of audio latency, shouldn't really be a concern. There is no guarantee of timing vis a vis audio for main thread event-world code. Inside of Live, calls to the API are generally quick, but if you pile up a long enough calls stack, you might cause audio clicks.
As for ID reuse, that's really a question for Ableton. I am having trouble imagining an application where it would make a difference.
Well, in my experience, launching clips, scenes, or enabling the metronome, all take roughly between 10 and 40 milliseconds. Maybe there is a difference between "querying stuff" and "doing stuff" ?
Sorry, although I use it all the time, I don't know the correct terminology, and don't really know how it works under the hood. Is there any official documentation about this ?
explicit use [defer], [deferlow] for data to flow to UI visualisations and use [speedlim] object to limit the output of values. where it is ok for you. Apart from that use "Update limit" on UI objects somewhere at 20. ms or more and not the default 1. ms and also use checkmark for "Defer Automation". Otherwise without using those you expect the patch to run everything not only in main thread but at full blast together with the audio thread and very likely then also used [metro] for ui work where the almost identical [qmetro] object would be much better choice. If you do "recall 1 2 0.5" to [pattrstorage] interpolate your stored presets then you need for sure also place a [speedlim] in front of the interpolation value (float at the end of the message) because you can recall the interpolation on all linked values at once and produce a heck of computation without even noticing so obvious.
i guess the varname of objects is persistend, and i was also expecting obj-id to be persistent but the latter is not always the case.