I decided to take a little bit of time to discover how the integration of hardware controllers really works within Live. Up until now, a lot of people understood bits and pieces, but did not have the whole picture. We new that we could select a supported controller within Live and it would automagically map to Live functions. We could modify the functionality by using Max For Live. But, what we didn't really completely understand is what the, "control_surfaces" object and all of it's subcomponents really did.
What are components?
What are controls?
How do these different things relate to each other?
Click, "Read More" for the rest of the story
These are some of the questions that we had. So, I decided to journey into controller integration land in order to find out more. I had an idea that if i could get a unsupported hardware controller to map to Live then I might just find the answers i needed. The first thing I needed to do is decide on a hardware controller to use as a test device for my experiments. Jay from Livid Instruments had sent me a Ohm64 a while ago for review and I looked at it and realized that it would be the perfect device. It had all of the elements that make up a great controller for Live. The Ohm64 has a button matrix, sliders, knobs and all kinds of other tactile controls that were just perfect for what i needed. I had decided on the device and now came the hard part. How would i map the Ohm64 to Live?
The answer came from an even more elusive component to Live then the, "control_surfaces" object, called Midi Remote Scripts. These scripts are created in the form of Python code that maps physical hardware control to Live functions. But, how was I going to find out about these scripts that not to many people outside of Ableton HQ have really delve into? Luckily the answer came from a new website called remotescripts.blogspot.com. This new site pretty much started me out on a couple day journey that ended up in a pretty complete mapping of the Ohm64 to Ableton's Live software.
I am not going to get into, "How to create Midi Remote Scripts" in this article because there is already a site dedicated to the topic and I am not sure how Ableton feels about sharing the knowledge. I am not saying that they would care. I am just saying I do not know and I would like to keep a good relationship with them. What I am going to go into is how the Max For Live control_surfaces object and all of it's subcomponents really work.
So, Why did I even mention the Midi Remote Scripts and the whole control surface mapping if I am not going to go into it? The reason for mentioning the remote scripts is that they have a lot to do with the components and controls that you see within Max For Live. When you actually select a control surface in Max For Live that you want to use in a patch, you are actually selecting the python script that is associated with that control surface. The python script has a framework that it is based off of and includes all of the components and controls that you see within M4L.
What is inside this framework that you mention?
The framework includes components that are in reality, small applications, that serve certain functions. For example, there is a session component that's sole purpose is to give hardware access to Live's clip launcher and some other related functions. The session component will handle things like what hardware buttons control bank up and bank down? What midi messages should be sent to the controller when something is triggered in Live?
How do controls come into play?
Controls are the individual elements that make up a component. There are several types of controls that are in the form of EncoderElements, ButtonElements, a Button_matrix, and more. Each one of these individual controls is mapped to a control type and a midi message and then that control is mapped to a component. For example, A mixer component could have 8 SliderElements (Sliders), 8 EncoderElements (knobs), and 8 ButtonElements (Buttons). Each of these individual controls would then be mapped to the mixer component and the mixer component would then be called when the midi remote script was initialized (When you select a control surface under midi preferences or whenever you start live with a previous selection). The ned result would be that the mixer component takes care of the interaction between Ableton Live and all of the individual controls that are mapped to your controller.
Now the controls and components in Max For Live made a little more sense. I new that controls were individual elements that had python code based on the type of control and that components were little applets that contained the brains behind the mappings. The questions now became what can i do with this information?
The first thing i did was create control elements that corresponded to the Ohm64. Then I created session, mixer, and transport components in order to interact with Live's session, mixer and transport section. The result was that I created a fully functional integrated Live mapping that can be downloaded and dissected at Livid's site. But, I wasn't happy with the normal functionality. What I had learned is that new components could be created and called within Max For Live. This now meant that i could create new functionality in Python and call it as a component within Max For Live. I could do things like use network I/O and create python based sequencers and then use them within Max For Live. Although, I have not done any of this yet, it is all theoretically possible. My journey is still an ongoing one and the results should be very fruitful. Stay tuned for more in-depth knowledge on this subject.
More Info:
Remote Scripts: remotescripts.blogspot.com
Ohm64 Remote Script: Livid Instruments
wow thanks for the block remote script!
i hope it can become 'bigger' as maybe it is possible to control effects as well (with smoe sort of shift)
but thanks anyway