get varname from DeviceParameter
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?
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)… http://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 ( http://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):
----------begin_max5_patcher---------- 1174.3oc6ZssjahCD8Ympx+.EUxadnP2E6aYeN6WPpTSgMZlQYwBufvYlM09 uuBgACNdXT10Fab4W3htf59ntOzMz+38ual+hrmEE9d+l2W7lM6GlVlYaqpk YMMLyeU7yKSiKrCzWI9d1hu4OeaeZwyZa6Ed2c2c+UonTb+JQQQ7ih1wnJWk UpSEZ6SHro4kYoY40KdX.FPnb5byUPTDDXuBDFwCwy8.AgdesYVOjozp3UB6 h9obYbp2umklztXxDaOFY7NPaiqi0KeRpd79bwRc8RRvlGKhvBMKELBFPLqS HKHzbhu+5UH+a65ABCB6nTRUiNArM9Ou+cUmMml6LbtOV0hmeh68Avq.gf+K fAObH3fgnU5NDaOgpABZWfnd80urVTOCe+eQPBdB.I1wFjFzlgxAATLjCgSO jhdjQJFaPjBxBf7sdWSLjhbrQJ9f7PLXPjAp3QSOjBerQpnAQJCwLgAv.vzC oPGajhNDRgo3.H.CivSOjBdrQJxfHUXT0a9mZfD3XCRng.IDgb4BRoxMhfDi 10pAahy2o2c3dyyzYUhXam+A9y1YFnkpW5gxcBMEX01tG1oZ8Qd3NMdYYwhr 7DQduXbCm2+vtGz5bQgPoi0xLUOfGYQ7pCD6r38lV2svAIDXgDqviwUajG5Q 8y6fy87eHMKV2YqLdo1f1JgHIU3HD0Uy5YdFudsHNOVsTzC6VaZakPKxu2rO sHUzaN8i4d2TThzd.MzD9AlXSlvjAAJp5JjgyDy1S5Jh2HRtOVqykKJ0hcWU r0jqwlqxpJsTj8PS6sczUjSkp+rx5pm70eDYpGOfwYuwT7TVt9sFTyNU3g5b kwCo1cam+VuATpj5B8K0vazqNBq.7QSxYO7wCKoqqLEjqrBxgWoUl84JaQoJ QXkI91As0We2Em.me1j14Ozcm+giE2L6lrVtw.bYw.vbgAfccw.vFQF.5TlA .9K75e3fYNEQayF+FCvkEC.0EF.50EC.cDY.HSZF.2iA.9les6luxzMFfKKF .hKL.jqKF.xHx.fmxL..2iA.NXL.XNq8qmdiA3xhA.6BC.95hA.OhL.nIMCf 6w.fF7W7hQn1+JvMFfKKF.jKL.nqKF.zHx..mxL.tGB.Zvj.PLtsLWt46eQ4 6Ccw2Gdc46CGQeevj9u.3rq+fQ+if3at9Wdt9.Wb8AWWt9f210ud+w3Wq9op S0ZaW0wdDBEYk4KaLca9h3dfc6zIhBiOdqY3W5TFadcLHdRljHT8pS0DYQkg n0UK70IobWxnNIYU0q4XKYL2jLvYPxP8WyWQzdSAakLYclTo2ZWgn1Bi.xrk ADwPLRZpI3pl5rdGcEhbRTHLH5boPzSiBwPArlZY6LnUrShVQQz.FuiJLxZE +jnUDNL.2TKqmAsJ5znUPdPXScmN9Z09uG3HoUl3irE02YPg.mFWpHP.no37 Gcsp52u4R3F7Q+UmPGCDJZzkrpOWoKRFc7kLG2MIiuj43tI5+kjsM.bSn6aD 4Eae10BkI06uUmnEcd88RU880463mK1HalBoto3bS9nZSxnk404z7Lm5a5wt flC+K0CFj4C -----------end_max5_patcher-----------
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(<the bpatcher’s varname>).subpatcher().getnamed(<live.dial’s varname that is duplicated in other bpatchers>);
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). 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.