Live.remote~ cannot control two parameters at once ?

alain

Hi, sorry if this is trivial, but I am new to Live and its API.

What i am trying to do is to use the example in M4L.api.changetrackvolume, to control several tracks volume from an osc device.
So I did a small patch, attached, whcich allows me to select the ID of the volume of two tracks, and then change this volume manually with a simple number box. So far so good. But if I try to change two values at the same time, the volume sliders start jumping all over the place.

So my questions are:
- is this the wrong way to do this ?
- what would be the right way (preferably without using js)

I tried to make the patch self explanatory. You have to find out the ID of the volume of two audio tracks. You can then see how you can modify each volume with the number boxes.
When you use the box that says: 3. Modify two values at the same time ! you will see that the volume sliders do jump, even though I make sure I always send one value after on ID at a time...
Any help ?

Thanks

Max Patch

Copy patch and select New From Clipboard in Max.

Alain

broc

Changing ID is a timing problem. So you need to use 2 separate live.remote~ objects.

alain

Thank you Broc for your reply,

I guess this is a known 'feature' but I would not know where to find the information about it.
Exploring a little further I found some patch from rezo220 that shows nicely how to come around this with several live.remote~objects. (and I also noticed that I should use sig~in my patch to go into live.remote~)
http://www.maxforlive.com/library/device.php?id=621

Also, it looks like live.object is capable of switching IDs the way I need, So the question is: should I go that way or is it preferable to go for multiple live.remote (or live.object) or can I rely on the ID switching of the live.object ?

Thanks

Alain

broc

Unfortunately the timing behavior of Live API is not documented at all. But it has been stated somewhere that the timing is "sloppy" in general because GUI operations by design are running on low-priority threads. So ID switching of the live.object may also be problematic. Generally I prefer live.remote over live.object as it seems more efficient (eg. doesn't write to the undo history).

alain

Thanks again for your useful information, broc !
I will use multiple instances of live.remote~ then, and see how it goes...