The aumhaa Website has been transported, please go here instead:









http://www.aumhaa.com








We don't hang around here anymore.....

Search This Blog

11.12.10

Python is FUN!!

I'm getting the hang of this now.  I've been all over the _Framework now, and at last I understand exactly what is going on in there (well, as much as possible, since true understanding requires two things that I don't have:  the current decompyled versions of the scripts, and the backend code that its connecting to).

I've managed to create the necessary overrides to the _Framework so that a standard control script can be modified to include the ability to completely control the functions of the script from within m4l.  This means that, for instance, you want to tell the script that a button is pushed on the controller attached to it from m4l, you simply send a message to the corresponding button element with the new value.  This wasn't possible before, nor was it easy to achieve (er....it was minor, but it took me a long time to understand how to do it).

I've also managed to create a new Module that overrides the functionality of the ModeSelectorComponent.  It allows the ability to assign listener functions to different elements of the Control_Surface, and forward their values directly to m4l when their values change.  Those of you that have investigated the C_S portion of the m4l implementation have probably noticed that there aren't very many things that you can actually observe in the C_S objects.  In fact, there are only two observable properties:  'value' of __controls__ (which are not even a defined property within any layer of the __control__ heirarchy) and 'mode_index' of the ModeSelectorComponent __component__ (which does have a property, '_mode_index', but the property has a preceding underscore).   After tinkering a great deal with all of this, I've come to the realization that there is no general way to get an observable property from modifying the scripts, as there is specific functionality built into the backend code that connects Live to the Python implementation; it must search for specific instances of these modules and connects to staticmethod functions to retrieve their values when they change. 

So, instead of giving up, I created an override of the ModeSelectorComponent that allows it to be used as a ValueListenerComponent, and thus transmit the values sent from MidiMap in Live to the m4l side of things simultaneously.  Certain value changes can be intercepted in the scripts (usually button values), but most Midi data (bound encoders) is never forwarded to the script before being sent from Live to the controller.  This caused me enormous grief, but ultimately gave me a much better understanding of how the scripts work.

Bottom line:  the most current version of my scripts allows both settable and listenable properties for every connected control in a script accessible directly from within m4l.  This is how things should have been from the beginning....it is, I think, what we all expected regarding control_surface support when m4l was released. 

My motivation for doing this all this is to enable the use of Python for all control_surface purposes.  The _Framework is much faster processing things than m4l, so all I need from m4l is to be able to set and receive the values that would be sent to a Midi controller.  A new version of Monomodular will arrive shortly, which implements an iPad script with much less bloat, and much greater dexterity. 

I discovered some bugs with the Python bridge.  These bugs have to exist in m4l also, since it is basically just another Python script.  Its probable that Ableton knows about them, and has a way of avoiding them by not doing something that I'm unkowingly doing.  I will publish some more data about this when I get more information (I need to test the raw Ableton scripts to see if they are generating the same errors).  In the meantime, if anyone has questions please contact me directly.

1 comment:

  1. thats very interesting work youre doing there.

    ReplyDelete