What might be the simplest way to get all the device parameter ID's of a Live device which is on the left from a Max for Live device?
Hi there,
I hope to find some help here. I'm a little bit familiar with Max and I realized some smaller projects (audio effects, basic signal generators, some utility devices). Now, I'm about to learn how to control Live via a M4L device and I run into some difficulties.
My goal: I want to create a floating Max for Live device which mirrors Live's native Echo device (for use under certain live conditions).
I started with the rather easy stuff. I did a replication of the Echo GUI and a patcher with a zoomable floating window. Next step, controlling the Live parameter. With success, I reused some examples to create a bidirectional control (see GIF).
My issue: In my configuration, I need to map the parameter I want to control manually. And the way I catch the device parameter seems pretty convoluted – especially when I start to control 30+ controls (see PNG).
My question: what might be the simplest way to get all the device parameter ID's of a Live device which is on the left from my Max for Live device? (There is a similar example in the Building Max Devices pack, but I can't adapt it for my needs)
Thank you.
There are two ways to access a device, either by id or by path.
Get the path of your M4L Device by sending getpath to a [live.object] from this.device.
[zl.slice X] the device number
subtract device number by 1.
[zl.join] old path with new number
use an [live.object] to get parameter ids.
I can provide an example patch later.
Here is a patch that works:
Edit: I did not refreshed the website hence I could not see your example! Now I'm on time. Thank you for the patch. Yet I'm still not sure how to append the list of parameter ids to dials as I do in my example with [s---DeviceParameterID] and [r---DeviceParameterID].
As the device I want to control is always the same (Echo) maybe there is a static way to catch the parameters?
Okay. I now try to collect the list and get an overview of the device parameters. Is there any restriction, or just an coincidence that the list stops at 127 items?
I see, thanks @source audio. I now tried a different solution but still not sure about this all and now I feel a bit lost hahaha ....
However I keep on trying.
I wonder what kind of device has more than 127 parameters? Most Ableton devices just have about 10-40. Is it a VST?
Normal lists can just have 256 items. As SOURCE AUDIO mentioned, you can increase the max-size of lists. But be aware that you need to delete any message out of the chain, since messages are always 256 and can't be expanded.
I updated my device to include parameters dials. You just need to slice the list of id's with [zl.slice 2].
I am not having any problems with retrieving parameter values and setting new ones.
Or did I get anything wrong about your problem?
I lost the observers of the parameters on the way...
Here an updated version.
@Marc Assenmacher Thank you very much. You are quick! While I was about to implemented a clunky way to observer the parameters you made it simple. Your last patch seems exactly like what I was looking for. Let's see if I can build up what I want from here. Thank you again.
PS: No VST here. I had Operator in front of my test device. It turns out Operator has 128 parameter :)
Edit: I tried to change a dial to a toggle but do not work as expected. Any idea?
To get an even better understanding of the LiveAPI may I ask you (@Marc Assenmacher) what would be a "static" approach? As I want to only control Echo device, is it possible to do this "hardwire" the controls? (like I tried on the picture on my 4th post).
Both problems are actually really simple. You had the right approach.
Thank you again. This works like a charm for my goal. However for fun I tested the patch with other devices. And I get at some point a "zl: stack overflow" error. Only happens with Operator as it turns out Operator actually has 193 parameter (checked with Max Api DeviceExplorer). The error comes up with more than 128 [zl.slice 2]. I assume I can solve this with the @zlmaxsize attribute set to 193? Do I need to repeat this for every [zl.slice 2], or just the very first one?
Every [zl.] objects needs to be set to a higher number! The default max size is 256.
Your first test with the operator has only shown 128 entries, since "id" and the number are already two entries, e.g. 256. The operator has a list length of 193 x 2 = 386. To be on the save side just set the value to 1024. You only perform this once at launch or by dragging it. Don't need to worry about performance here.
why don't you strip "id" and work only with ID numbers ?
then where needed prepend "id" for live.observers and live.objects .
"zl: stack overflow" error does not come from too long list,
but something else in the chain .
@source audio
Right, I still get the "zl: stack overflow" error, although I increased the "zlmaxsize". Operator has 195 parameters. Addressing the parameter the way I do now works up to 128
parameters. I'm not sure where the error comes from.
I also thought about to address the parameters directly instead of creating a list – is this what you mean too? Could you help with an example? Thanks
I am not using Live.
Can you tell what you want to do ?
Maybe ALLWAYS address 3 parameters of that known device ?
if so, get the first ID.
the rest will be consecutive.
In this case 14812, 14813, 14814 for 3 first ones.
you also don't need to querry names, you know them allready.
put them into umenu, and add ID offset to umenu numeric output.
Another thing is - you can ask if there is a device in selected track
named like what your effect is.
if yes then get it's first param id, and off you go.
Those are dynamic IDs. If I understand the LiveAPI right, there are dynamic IDs and static IDs. The parameters IDs of Live's devices are static but becoming dynamic on a higher level depending on the Track where the device is on, the place in a chain etc. I'm sure I can call the static ID and control it, but I'm not sure yet how.
In the beginning, I wanted to mirror a native Live device in a floating window, see my first post. This went well, and I'm working on to finish this project. Then I tried to do something similar, just differently, with a different device to get a better understanding of the LiveAPI. This evening I'll find some time to do some more research on this.
I meant that you don't have to query parameters of known device every time.
if that ECHO gets assigned id 444 for first parameter, all following parameters
will get 445, 446, 447, 448, etc.
Their names, min/max range ... whatever else they have are allways the same.
if you have umenu populated with all parameter names and that data,
you don't need to query that again and again .
just pick parameter and add id offset, in this example + 444
That can be done simpler, for example with regexp \\d++
Only ints get through.
Example to populate umenu with parameters id/names
from device placed before this one.