Ableton Forum

amounra93 wrote:@ Hanz: I'm still having trouble wrapping my head around how the _Framework classes handle add_value_listener methods; I can add them manually myself, no problem, but can't figure out how to hijack the listeners that are already created by the scripts. It seems like the only component with a listenable property is the ModeSelectorComponent, and I'm obviously just missing something about how it operates.

I think what can be done here is to create a super-class to wrap the original c_s class in, and define some basic utility functions inside that class that aren't necessary to the _Framework stuff, but can operate on top of it. Basic listener functions to be initiated after the main c_s class is constructed, some tuple_wrappers, the sysex_out stuff we already figured out for talking directly to the control surface (mainly for control_surfaces with LCD's or other unordinaries), and whatever else might be needed.

I don't even know if that is possible...theoretically, I think it is though. If it works like that, there would be no need to modify any of the existing _Framework docs or compiled scripts...all the additional functionality could be attained in the top Class, and other sub-classes could be added to deal with API stuff that's not included in the _Framework already. Thoughts?

class TupleWrapper(object):
	__doc__ = ' Wrapper class for the access to volatile lists and tuples in the Python API '

class StringHandler(object):
	__doc__ = ' Class that can parse incoming strings and format outgoing strings '

amounra93 wrote:The "add_value_listener" thing: this is how Live knows to trigger a function whenever an internal mapped value changes that the notifying controller is mapped to (or something like that). I'm trying to find a way to link another callback to this same dictionary, so that we can also receive notification to an observable property in m4l.

I'm basically trying to determine what makes the ModeSelectorComponent differ in its ability to send a change notification when its _mode_index changes, while other similar components do not have observable properties.

Practical application: iPad w/TouchOSC. I would prefer to create a Python script as the framework for the iPad controller, but still be able to manage the interaction with that script from m4l. Its currently impossible to change properties of Live's functionality via a c_s python script from backend of the script. You can send a MIDI value to change something in live (e.g. Volume or Pan) from outside live, but if you try to use receive_midi in the Python script, it will change the current value of the controller in the script, but will not affect the associated control in Live. Does that make any sense?

EDIT:: actually, they're kind of completely different issues, but in the end they relate to the same thing. If we can get updates from the scripts regarding the current state of their associated controls, we will be better able to utilize the scripts in a creative way. Thus "hijacking" the listener dictionary already created by the components/controls and triggering a function that changes a listenable property (by listenable, I mean on that we can observe in m4l).

"add_value_listener" simply maps a control to a function; the listener function is where the action is. ModeSelectorComponent is no different than any other component, but it just so happens that it has a listener function whose purpose is to set the mode property (_mode_index), which I assume is observable via M4L.

Now, since M4L can talk directly to Live, and can also talk directly to a control surface, why would you want to change a control surface script property, and expect a Song state change, instead of making the change directly to the Song state and then either allow the script to do its job and update the control surface, or change it directly from M4L as well?