Forums > Max For Live

Live.remote~ cannot control two parameters at once ?

September 25, 2011 | 7:30 pm

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

Alain

– Pasted Max Patch, click to expand. –

September 26, 2011 | 11:17 am

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


September 26, 2011 | 12:11 pm

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


September 26, 2011 | 1:03 pm

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).


September 26, 2011 | 2:31 pm

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


Viewing 5 posts - 1 through 5 (of 5 total)