ok, I hope you understand what I tried to describe there :
As it turns out that the live.API request answering timing could fluctuate in very large amount depending on the complexity and number of m4l devices, I really would like to have some ways to know When the the answer is complete.
AFAIK , there is only one request who sends a "done" when complete: "getinfo"
I wish I could have such a message when I ask for the devices on track or their parameters.
So it will be possible to build a reliable cascade scheme of requests.
So far I use some [delay] to "secure" things but I really don’t like this.
Does this makes sense ?
one workaround could be to use a live.observer observing the property you change for the live.object. when the value is updated by the observer in the patch, it means "done"…
critical real-time things should be done differently… by reading you.
I mean: if you need a kind of "done" message, it probably means cpu has a lot of things to do. So, in order to have this "done" message, you want to build another "system" that handles the completeness of processes to inform you with "done" messages…
so cpu would have more work to do…
it doesn’t make sense for me :P
I’d choose another way…