wellis

I think I know what answer I'm going to get, but thought I'd better ask just in case. Is there any way to ask live.object for the varname of a DeviceParameter?

get-varname-from-deviceparameter

Given no response to this, I think I know that the answer is no ;)

However (asking anyone from cycling74), is this on a roadmap at all? It seems to me that this is a bit of a gap in the toolset, as I have no way of resolving situations where controls have the same short name.

N.B. This is quite a common occurrence if you are implementing for Ableton Push and only have 8 characters. Example would be FineTune for each of two oscillators on a synth, which are displayed on two different banks of the Push, whereby the duplication is not an issue.

Not quite sure what you're asking here... you want the name of a device parameter?

In the list of attributes of a Device Parameter in the LOM, the only available names are name and original name (both of which relate to Short Name)... 

https://cycling74.com/docs/max5/refpages/m4l-ref/m4l_live_object_model.html#DeviceParameter

It would be really useful if the LOM exposed Scripting and Long Names too ( 

https://cycling74.com/docs/max5/refpages/m4l-ref/parameters.html

 ), especially Scripting name, as that is unique. That would allow you to find a specific control that you want to set the value of, or otherwise query.

In the list of attributes of a Device Parameter in the LOM, the only available names are name and original name (both of which relate to Short Name)... https://cycling74.com/docs/max5/refpages/m4l-ref/m4l_live_object_model.html#DeviceParameter

It would be really useful if the LOM exposed Scripting and Long Names too ( https://cycling74.com/docs/max5/refpages/m4l-ref/parameters.html ), especially Scripting name, as that is unique. That would allow you to find a specific control that you want to set the value of, or otherwise query.


ok, I see. Remember when you use the LOM, you are talking to Live, not to MAX and so not all of these concepts exist. For example, these is no scripting name for a parameter as that is a Max concept...

These is however the Live path for a device parameter which will be unique within the current set (tho subject to change if moving stuff around)

Oh, of course, understood, but I am talking about asking the question via Live-specific objects.

My specific use-case is maybe slightly unusual, in that I'm trying to write something that is easy for other end-users to customise, with changes to parameter naming and layout, but retains a fixed mapping to an external parameter set.

Hmmm.. still confused by "It would be really useful if the LOM exposed Scripting and Long Names too" then - the LOM is just a m4l wrapper around the pyhton API into Live.. So when you say scripting and long names too, are you saying that you wish Live exposed scripting and long names too??? (or have I just lost the plot)

maybe a small real-world example might help? or someone else may understand better than me :)

Sorry, I know I'm probably not making a lot of sense, as I'm not very experienced with the LOM!

If you imagine that I have a set of live.* objects (e.g. live.dial) which have a relationship with a parameter in another program that I am controlling. I want to be able to set up bidirectional communication across this link.

At the moment, I just use a simple message system "paramname rawvalue" coming out of the Max For Live object's raw value, e.g. "A1 0.003" means set my A1 parameter to 0.003. This then gets forwarded on to my external program.

Now the problem comes when I want to tell the Max For Live object that someone changed the parameter in the external program. I want to be able to navigate the LOM to find the Device Parameter that has a specific name (in this example A1) and then set its value.

Because the protocol I'm creating means there is a fixed set of possible parameters (128 parameters in groups of 8 from A1 to P8), I want to be able to use an identifier that isn't then displayed in the Live GUI or on the Push, hence Scripting Name, ideally.

In case it helps, this is an example of how a set of 8 live.dials is patched at the moment (the send goes off to my mxj~ code):

so it looks as though you're not actually interacting with Ableton?

even though you are using live.* objects, if you're not actually using the LOM unless you are talking to Live... is this the case?

so it looks as though you're not actually interacting with Ableton? 

even though you are using live.* objects, if you're not actually using the LOM unless you are talking to Live... is this the case?


I understand the issue and am having the same problem.

I am using js to script several bpatchers. These bpatchers contain instances of live.dial, each of which is connected to a separate live.object (with a unique live path).

When using js, pattrforward, etc to access these live.dials, each live.dial's varname is accessed by a unique path within Max. For example, in js it would be via this.patcher.getnamed().subpatcher().getnamed();

When having multiple bpatchers, each containing a single instance of an identically named live.dial, the varname is correctly assigned. HOWEVER, the short name and long names are assigned an iterative suffix (ie GAIN[1]). While the long name must always be unique within the amxd file, this is not the case for the short name (since I want each of my bpatchers to have a live.dial labeled "GAIN").

As such, while I am able to go back and manually change all the short names, this is a terrible solution, and as such the desire is to be able to set the short name during the scripting process.

The benefits of using live.dial (or other live.(objects)) include the 0.-1. output and the integrated short name label. While a workaround would be to script the live.dials with showname=0, and create a separate comment object that would show the proper label for the live.dial, such a solution would be excessively cumbersome.

I understand the issue and am having the same problem.
I am using js to script several bpatchers. These bpatchers contain instances of live.dial, each of which is connected to a separate live.object (with a unique live path).
When using js, pattrforward, etc to access these live.dials, each live.dial's varname is accessed by a unique path within Max. For example, in js it would be via this.patcher.getnamed().subpatcher().getnamed();
When having multiple bpatchers, each containing a single instance of an identically named live.dial, the varname is correctly assigned. HOWEVER, the short name and long names are assigned an iterative suffix (ie GAIN[1]). While the long name must always be unique within the amxd file, this is not the case for the short name (since I want each of my bpatchers to have a live.dial labeled "GAIN").
As such, while I am able to go back and manually change all the short names, this is a terrible solution, and as such the desire is to be able to set the short name during the scripting process.
The benefits of using live.dial (or other live.(objects)) include the 0.-1. output and the integrated short name label. While a workaround would be to script the live.dials with showname=0, and create a separate comment object that would show the proper label for the live.dial, such a solution would be excessively cumbersome.


Sorry to dredge this up, by any chance does anyone have any more insight into this? I'm in a similar position - trying to get the parameterID or parameter long_name from a parameter who's long_name may change on account of being in a bpatcher. I can access the object with by its varname no problem, but correlating that varname to its parameter long_name seems not all that possible. I understand that setting the long_name programmatically could theoretically get hairy, but not even having read access to it seems limiting. Any tips? Am I missing something?

Sorry to dredge this up, by any chance does anyone have any more insight into this?  I'm in a similar position - trying to get the parameterID  or parameter long_name from a parameter who's long_name may change on account of being in a bpatcher.  I can access the object with by its varname no problem, but correlating that varname to its parameter long_name seems not all that possible.    I understand that setting the long_name programmatically could theoretically get hairy, but not even having read access to it seems limiting.   Any tips?  Am I missing something?


get varname from DeviceParameter