Issues when adding live.remote~ objects dynamically
Hi there i hope everyone is good!
I have noticed a bug with max for live that i hope would be easy to fix.
I am making a m4l device that requires adding live.remote~ objects dynamically, they simply don't work when doing so: when sending the appropriate id to the object the parameter doesn't get mapped.
I made a m4l patch that demonstrates that:
First map a paramater in live (a knob or anything) as described in the device, you will notice that it gets mapped just fine;
Then open the patch, delete the live.remote~ object, save the device, and close the max editor;
Now press the right button in the device to dynamically add a live.remote~ object and connect it in the exact same way it was before you deleted it;
Now when trying to map a paramter in Live as stated above it doesn't work.
It would be very nice if someone from the Cycling '74 could check this out.
Thanks in advance.
This has been the case as long as I can remember.
@C74: assuming there’s a technical reason for this limitation it would be appropriate to add documentation about this to live.remote~ and “limitations of max for live”.
it would be way cooler if it just worked, though ;)
Bumping this as I need it, too.
The solution I went for is having a lot of live.remote~ objects in a patcher (250 is the max number of signal inlets in a patcher) and connecting them dynamically. I hope this helps
I did the same, fwiw.
Bumping this as I need it, too.
It is conceivable that we could use one live.remote~ for MANY parameters, for example 128 parameters for one live.remote~. Here is how:
Map the live.remote~ to a live.dial. The live.dial has a float data type. The range of the live.dial is 128*128 = 16384. The patch would simply use bands of 128 values for each parameter. For example, parameter 1 would send values 0-127, parameter 2 would send values 128-255, and so on. The target device would simply decode those values and use them to control whatever.
The only possible issue I can think of is bandwidth limitations. live.remote~ objects seem resilient to fast data inputs, but I have never tried them with such a large range. IIRC, MIDI is a serial protocol, and one MIDI port can handle 16 channels of 128 notes plus at least 128 CCs, and it seems reasonable to think a live.remote~ would be up for the task.
If that works, then you could control a lot more target parameters with a lot less live.remote~ objects, and that would make storing banks of live.remote~ objects in a single source device a lot more performant.
Before I set up some tests, can anyone think of any wrenches to throw in this idea?
Thanks
This is interesting! I'm currently also working on a m4l device with randomization controls that are clogging up the undo history in Live. I've been trying to wrap my head around how I can dynamically "get" the ids of all the live.dials I want to control upon patch load, then assign live.remote~(s) to them all and change the parameters this way. But my issue is that the ids of these live.dials are new each time the patch is loaded. How are you guys getting around this?
@IAN JOJO here is an example JavaScript code snippet that is similar to what I use. This requires familiarity with the LiveAPI and JavaScript, which is beyond the scope of this message.
api = new LiveAPI("live_set"); //I declare my LiveAPI objects in the globals section
api.goto("live_set tracks 0 devices 1 parameters 0");
var maxObjLiveRemote = this.patcher.getnamed("r1");
maxObjLiveRemote.message("id", api.id);