control_surfaces controls EncoderElement
I’m trying to send just the midi cc value to the encoder element of a User Remote Script, so that my controller can access the corresponding macro or parameter whichever device in Live has the blue hand.
The User Remote script has it’s cc settings for the 8 encoders, plus 3 more for "Lock Device","Next Bank", and "Previous Bank".
Toggling the lock works fine from the [control_surfaces x] level, and I can do the same at the [cs x controls x ButtonElement] level using "receive_value 64".
Next/Prev Bank seem to work the same way although the switching isn’t displayed in Live’s status bar as it should.
The main problem is the EncoderElement. "receive_value x" doesn’t seem to work, and I’m also wondering about the "id 0" that is appended to the message the live.object prints.
If "receive_value x" isn’t the correct function, it doesn’t seem like any of the others are either.
Anyone know how to do it?
I wasted a lot of time on this myself long ago. It’s hard to explain whats going on without a lot of details, but the short answer is, "you can’t".
In this instance, Python is telling Live to directly map certain controls to functions inside Live. Even though internally there is a "receive_value" function, it doesn’t do what you would think it does. Basically, when the DeviceComponent assigns a knob to a parameter, all the script is doing is telling it which parameter to assign to which knob. Live does all the heavy lifting, and the ‘receive_value’ is there for monitoring the state of the control when it’s turned.
Although it is possible to get what you’re looking for through Python (I’ve done it in Monomodular), it’s much more complicated than it appears (but probably much less complicated than I’ve made it hehe). It’s not possible with the vanilla _Framework; it requires a lot of hacking around.
If you’re Python savvy, you can use my _Mono_Framework to do what you want, but it might be overkill, and those bits aren’t documented.
Hope that saves you some time, at least ;)
It does save time, and just getting a solid answer brings some relief. Thank you!
Still though, even using [send_value x] to an observer works with EncoderElement, as it reports the corresponding param value from Live’s device, so apart from ButtonElement working fine, and send_value from the EncoderElement also fine, it seems strange that the only thing that isn’t supported is the receive_value for EncoderElement….
Anyway, I have spent some time learning python basics and perusing a lot of scripts and the usual remote script info all over the internet, and knowing the LOM gives me a better understanding of scripting. I will check your site again (went through it some time ago but haven’t put time in playing around with monomodular stuff) and take a look. While you have stated the pro’s and cons of M4L vs Python, there are numerous other pros with M4L; a big one for me is being able to provide some helpful GUI elements.
For now though going the hack route is overkill, since the only real benefit is accessing the banks from devices.py. Some people have customized it and it’s supposed to have a more rational/usable layout so I may just incorporate that into a dict instead and stick with straightforward [selected_device] control. This will also free up a CS slot in Live preferences:p. The python/M4L relationship seems very intriguing however so I will explore that after I get a decent M4L CS device out which already has a lot of functionality, and in my early excitement I led people to believe I would have something for them awhile ago:|
Oh Mighty AmounRa, Your Wisdom Is Unbounded! :P
Forums > Max For Live