Controlling Ableton: APC40, Max for Live - what do you think?

[Melonenmonster]

Hello Midiboxers,

sorry for entering the forum here with such a commercial topic,

but after making the 4x20 LED Matrix and especially the monodeck II

quite a few people contacted me about controlling Live. We couldn't

really help because the API used by monodeck II was proprietary and closed.

Now AKAI and Ableton have announced the APC40 which I think is something

you really won't like, or at least won't care about, because you make your own

stuff - devices which blew me off many times by their beauty or coolness, or both.

The 4x20 LED Matrix was a very early step in what ended now in the APC40.

But I personally was not involved in that project since end of 2006, because I

took care for something which could interest you much more - Max for Live.

My hope is that MfL will allow you to control Live from your MIDIBOX based

controllers in exactly the way you ever wanted. There is still a lot of work to

do to get it out, but during this time there will be a moment when the first

version of the API to control Live from Max will be stable enough to be published.

I will post it here asking you to make some comments which we could use to

correct some mistakes or inconviniences, of course, but most of all to see

what is missing and most wanted, to have an input for the second version.

What do think about that?

Melonenmonster aka. Ralf Suckow from Ableton

[audioworld]

Hi Ralf, this sounds very promising to me.

When I read all the news about the new Akai hardware and MaxfLive I did not think that the protocol between APC40 and Live would be available for general usage (maybe this is not what you suggest, maybe you mean an intermediate API which only works with MaxforLive). In any case, I am sure many builders here around would be heavily interested in any kind of API for Live, and I am happy to read that there is some open communication from ABLETON "Headquarters" to a DYI-project like the Midibox. I myself bought Live 4 years ago and use it ever since for every gig (now on version 7, of course) along with my MIDIBOX hardware, so I will definitely watch your future postings.

[ultra]

ralf,

i'm struggling to understand this post for a couple of reasons.  the first is that liveapi does exist.  in fact, i've been working on a system that allows any midibox user access to live that go beyond the new akai controller and the monodeck II.  i'm even able to access track, clip, device, and device parameter names and put them on the midibox, after automapping the midibox to each control.  feedback on clips is an easy one.  so the system exists, it's just that we weren't really told about it and how to use it.  which leads to the next reason i'm confused.

the monodeck II was built using an open-source system with information provided by tk and the midibox community.  however, i've yet to find any information about the monodeck II that was given back to the community (edit: i've found information on the hardware, but nothing on the software/communication).  i have looked, because of my interest in getting under the hood with live.  it was a bit disappointing to find nothing.

now we're being asked about how to improve a commercial product, after having been slighted on information regarding how to control our own devices.  are you providing max for live for free?  or do you want us to purchase it and tell you how you can make it better?  how is this nothing more than a max for live advertisement being posted to the forum, when we already have a means to control live but are told it doesn't exist?

[Just Phil]

hi ralf i have been holding back building my midibox for this exact release. max for live. i heard about the cycling '74/ableton collaboration during the beta planning stages of my midibox. so i have been learning ableton and max inside out until this happens.. i was originally inspired by the monodeck which I understand you had a hand in. when i saw robert play live here in toronto i knew i had found what i was meant to do. i have been patiently waiting for this release and it means that my whole live performance will shortly be realized. pending financial stability.

do the max for live plugins have their own ram adressing? i plan on recording many tracks to long buffers for processing inside the max plugins. and am worried about hitting the ableton's maximum ram allowance.

oh and THANK YOU FOR MAX FOR LIFE. Greatest product to ever happen to me.

[Melonenmonster]

ralf,

i'm struggling to understand this post for a couple of reasons.  the first is that liveapi does exist.  in fact, i've been working on a system that allows any midibox user access to live that go beyond the new akai controller and the monodeck II.  i'm even able to access track, clip, device, and device parameter names and put them on the midibox, after automapping the midibox to each control.  feedback on clips is an easy one.  so the system exists, it's just that we weren't really told about it and how to use it.  which leads to the next reason i'm confused.

Ultra, as you know, Ableton was aware of the LiveAPI, and although it was a hack into the inner parts of Live and thus a violation of the license, ableton decided to not only tolerate this attempt to get an API to control Live, but welcomed it. The reason is that we knew a demand for such an API exists, and people were putting thier efforts into it, but we also appreciated their skills as engineers. We looked if a community would grow around this, but that seemed not to be the case, most likely because it was too difficult and unreliable to use it.

You must understand that an internal programming level is something completely different than an official API provided to the users. The internal API may change with each release, even with each bugfix, and render your efforts useless. It is not reliable, not documented, not complete, not polished, uses internal terms, is not orthogonal and hard to use, and its very easy to make mistakes and loose your work (i.e. the Live set). Therefore we had to say that no API existed for the users to control Live.

Making such ann API from the internal layers is a significant effort and for MAX for Live we are doing that. We had to build an infrastructure for handling the user-made programs (patches) anyway, so we used the chance to extend MAX with objects to control Live. We took care to make a nice and understandable API and data model, we will document them, test them, fix bugs and keep them as stable as possible over time. So that we can say without shame, yes we provide an API.

the monodeck II was built using an open-source system with information provided by tk and the midibox community.  however, i've yet to find any information about the monodeck II that was given back to the community (edit: i've found information on the hardware, but nothing on the software/communication).  i have looked, because of my interest in getting under the hood with live.  it was a bit disappointing to find nothing.

The extensions of MIDIBOX software needed for monodeck II are documented here:

http://www.suckow.de/ralf/ledmatrix4x20/index.html

The actual software in the monodeck II is slightly different, but since I had no time to document it (again), I just sent the software as is to the people who asked, which were 3 or 4.

The huge Max patches which actually implement all the logic in Live are made by Robert and are his secret (his competitive advantage as musician, if you like). But this has nothing to do with the monodeck, with MIDIBOX, with ableton or with me. Most technical musicians keep their personal way of making music, their tricks, for themselves.

now we're being asked about how to improve a commercial product, after having been slighted on information regarding how to control our own devices.  are you providing max for live for free?  or do you want us to purchase it and tell you how you can make it better?  how is this nothing more than a max for live advertisement being posted to the forum, when we already have a means to control live but are told it doesn't exist?

You are right, that was a stupid move of mine. It has nothing to do with ableton. I was a little homesick about the MIDIBOX community, which I had no contact with for two years, and then I thought it would be cool to get some feedback on the API so that we could improve it, maybe even before the release. But I forgot that this is a completely non-commercial thing here, which I must respect. Also I became weak and allowed myself to show off with something I though would be cool in the eyes of the MIDIBOX community. You are right, please forget my post.

[Melonenmonster]

do the max for live plugins have their own ram adressing? i plan on recording many tracks to long buffers for processing inside the max plugins. and am worried about hitting the ableton's maximum ram allowance.

They run inside of the 32 bit Live process and thus are limited to the 4 GB RAM limit (3GB on Windows). I cannot say anything about 64 bit at the moment. But I guess you could record into files using Max and then stream/process them, if that would help. At least that's what Live is doing. Another possibility is to start new child processes from Max and communicate with them, using TCP/IP for example. Each of them could hold their own 4GB then. I don't know how much physical RAM you have or need, though.

[Melonenmonster]

Hi Ralf, this sounds very promising to me.

When I read all the news about the new Akai hardware and MaxfLive I did not think that the protocol between APC40 and Live would be available for general usage (maybe this is not what you suggest, maybe you mean an intermediate API which only works with MaxforLive).

Max for Live provides Max objects which allow to control Live, opening a significant part of the internal APIs, abstracted to the user level, where a set is a set, a clip is a clip, and a device parameter is a ... you name it.

In any case, I am sure many builders here around would be heavily interested in any kind of API for Live, and I am happy to read that there is some open communication from ABLETON "Headquarters" to a DYI-project like the Midibox.

I'm speaking here as a private person, but I decided to be not only melonenmonster this time, because you should know that we are thinking about you when we do such things and when we have to decide where to put our efforts.

Ralf

[dstamand]

Thank you so much Ralf !

[intellijel]

I am one of the guys Ralf gave the files to and he was also really helpful about answering questions. He is definitley supportive of the midibox/diy community!

I have also been following the LiveAPI project for quite a while and was able to make some interesting prototypes but I gave up on the project for the exact reasons that Ralf stated. I was too worried that something would get broken on subsequent Live releases and the whole time I was pretty much waiting for the MFL features to be implemented.

That being said I found the APC40 to be a disappointing controller but it at least demonstrates some of the new potential. It is definitely encouraging me to finish my own custom controller in time for when MFL gets released. Looking at how the APC40 integrates with live gives me some insight as to what my controller should be able to do as well (since it can use the same functionality/protocol via MFL).

I look forward to more details about the MFL objects so that I can plan even more functionality but I guess for now I should be patient.

I see Ralf's invitation to suggest features and changes as golden opportunity to help the DIY community, not as a means to increase Abelton revenue. Part of the reason the DIY community exists is as a reaction to the fact that most corporations don't listen to their users or create documented, open API's. For once there is a company that is doing this so we should encourage it...I think it will help the DIY community more than it will help them.

[ultra]

maybe i've jumped the gun a bit.  at least, i'll take your word for it that you're not just here to market MFL.

i have a few questions:

will we have access to the protocol that MFL uses, so we can choose not to use it and still gain control over live?  i'm not expecting a "yes" to this answer, but i figured i'd ask anyway.  i don't see why an additional control layer is necessary when i've accomplished all kinds of control over live without it.  in fact, i've managed to do pretty much everything i wanted to.  my only concern with it is what you stated, that it can change with versions.  but it sounds like you have something pretty much solidified, and with MIOS32 supporting OSC, we could have a nice tight integration with live without the need for an additional control layer.  i am very interested in what MFL has to offer, and i'd like to be able to control these step sequencers in the way i'm able to control any other kind of device on a track.  if you're interested in knowing how this particular diy builder wants to take control over live, i started a thread a while ago that completely describes the controller i'm planning: http://www.midibox.org/forum/index.php/topic,12636.0.html.  i've tested pretty much every aspect of this controller's description, and i think it's all currently possible.

i also have another thread where i describe a live controller that sounds very much like the akai controller that was just announced.  http://www.midibox.org/forum/index.php/topic,12585.msg106255.html#msg106255

does the akai controller require MFL to work?  if not, do we get access to the same thing it uses?

is liveapi going to go away with live 8?

with MFL, how will control over master sections (such as transport) work?  to my understanding, max is used as a device on a track, and i'd assume it's there to control track-related items.  i can see how getting at info on tracks could be made easier, but what about controlling live in general?

thanks,

ultra

[julienvoirin]

i also have another thread where i describe a live controller that sounds very much like the akai controller that was just announced. 

:o

http://www.midibox.org/forum/index.php/topic,12724.0.html

as a reaction to the fact that most corporations don't listen to their users

I guess they did it when a opened my BIG mouth a while ago

http://julien.voirin.free.fr/4Colors/Home.html

it was my memory of end of study. And I guess I wrote to Ableton.

will we have access to the protocol that MFL uses, so we can choose not to use it and still gain control over live?

it would be idealisitic

But i would just precise that Live is Mackie Control Compliant, that you can edit a script in order to use your controller as a Mackie MCU (that's the way they do to propose so much Control surfaces in the Preferences : they did a generic and map everybody on it), that the protocol allows you to have  4 directions arrows, and that clips can be triggered like this. It is the way i am working on to control live. MFL is not useful in this case.

For me MFL is powerful as it can transform your controller, like the seq they did and can be mapped to the buttons of the APC matrix.

[Sasha]

...I see Ralf's invitation to suggest features and changes as golden opportunity to help the DIY community, not as a means to increase Abelton revenue. Part of the reason the DIY community exists is as a reaction to the fact that most corporations don't listen to their users or create documented, open API's. For once there is a company that is doing this so we should encourage it...I think it will help the DIY community more than it will help them.

I agree. Even MB is non-commercial community, MB is not concentrated only around free stuff. I`m sure most of MB hardware is used in conjunction  with  commercial software and hardware.

I think it would be cool to have access to the protocol MFL uses, but if this not happen, which is likely, ultra is already doing great job without it. Thanks ultra. ;)

@Ralf

Glad you are back. You are welcome here! ;) What you did with LED matrix for Monodeck II is very cool and it is my ultimate goal for controlling Live. I saw Robert`s presentation of Monodeck II at DisPatch festival here in Belgrade, and from that moment I want it even more.

[Melonenmonster]

maybe i've jumped the gun a bit.  at least, i'll take your word for it that you're not just here to market MFL.

i have a few questions: ...

Ultra, thank you for your reply. I'll need a little time to prepare some material for the answers

and also to look at yours.

Ralf

[Ashiman]

well , if someone could customise Ableton to the level of fruityloops8 (dont laugh its pretty good at what it does) I'd surely look into this.

What I use now is adding/subtracting/ doing math with multiple LFO's with nice visual feedback under midi control (i also use this module to mix LFOs) :

http://flstudio.image-line.com/help/html/plugins/Fruity%20Formula%20Controller.htm

Curve fitting envelope under midi control:

http://flstudio.image-line.com/help/html/plugins/Fruity%20Envelope%20Controller.htm

-are these possible (i really duno) ???

-anyone knows of a state-of-art LFO module for maxmsp? (I tried hard to find, 2hours in it so far)

individual control over 32 step (time offset, swing %, velo etc) would be hell-a-tight...

[Melonenmonster]

will we have access to the protocol that MFL uses, so we can choose not to use it and still gain control over live?  i'm not expecting a "yes" to this answer, but i figured i'd ask anyway.

MfL will be the only offical, legal, reliable and supported way to do it.

i don't see why an additional control layer is necessary when i've accomplished all kinds of control over live without it.  in fact, i've managed to do pretty much everything i wanted to. 

You are right, to provide Live control we tried to use what we have as much as possible. The layer on which the LiveAPI-hack is build is actually the software used to implement the support of all the different hardware controllers. We extended this layer by new functions (like note access) and put software into it which would allow us to keep the Max interface to it as stable as possible when the internal data model changes. Also we have to manage the relation to Max objects, send notifications etc. 

my only concern with it is what you stated, that it can change with versions. 

Some parts of the layer which you use via the LiveAPI have significantly changed with Live 8, others not. So, indeed using MfL will be more reliable.

but it sounds like you have something pretty much solidified, and with MIOS32 supporting OSC, we could have a nice tight integration with live without the need for an additional control layer.  i am very interested in what MFL has to offer, and i'd like to be able to control these step sequencers in the way i'm able to control any other kind of device on a track.  if you're interested in knowing how this particular diy builder wants to take control over live, i started a thread a while ago that completely describes the controller i'm planning: http://www.midibox.org/forum/index.php/topic,12636.0.html.  i've tested pretty much every aspect of this controller's description, and i think it's all currently possible.

Well, a nice and quite original design. Not one of the Mackie HUI lookalikes you see each day.

does the akai controller require MFL to work? 

No, there's the usual control script for it.

if not, do we get access to the same thing it uses?

I don't know exactly what the communication is between Live and the APC. AKAI says its proprietary, so I guess the APC script can be used only for the APC.

is liveapi going to go away with live 8?

The software layer still exists, although it has changed. I cannot say if the hack will keep working.

with MFL, how will control over master sections (such as transport) work?  to my understanding, max is used as a device on a track, and i'd assume it's there to control track-related items.  i can see how getting at info on tracks could be made easier, but what about controlling live in general?

Using the live.path object in any Max device, you can "goto" the Live set and from there to any track or its content like clips or devices, and start doing something with the objects there. You can also go to the loaded controller script and hook up your own functions, like Jan Buchholz did in the video to use the APC to control the notes in a midi clip.

Yours,

Ralf

[Melonenmonster]

well , if someone could customise Ableton to the level of fruityloops8 (dont laugh its pretty good at what it does) I'd surely look into this.

What I use now is adding/subtracting/ doing math with multiple LFO's with nice visual feedback under midi control (i also use this module to mix LFOs) :

http://flstudio.image-line.com/help/html/plugins/Fruity%20Formula%20Controller.htm

Curve fitting envelope under midi control:

http://flstudio.image-line.com/help/html/plugins/Fruity%20Envelope%20Controller.htm

-are these possible (i really duno) ???

Things like that are typical uses of Max, although I must say not all users of Max do care to make the interface as beautiful as the FL Gui.

Some of them make even nicer interfaces, though.

There is still a drawback of using LFOs to control Live parameters directly: you fill up the undo history, especially if many parameters are LFOed. We have no simple solution for this yet. Thus we avoided to control one parameter by another one, instead, let both work on a common signal processing.

[Max Romantschuk]

I personally have no experience with Live, but I do know a fair bit about designing successful standards and protocols... Make it as open and well documented as possible. The more accessible the information on how to implement the protocol is, the more likely it is to be adopted. I've seen a lot of great technology fall due to the fact that it was poorly documented, or alternatively the documentation wasn't made freely available.

Making a custom protocol is a double edged sword. On one hand it gives the greatest flexibility, but then again adopting an existing open protocol (Open Sound Control, for instance) could be a good option as well. Not that I claim to be able to judge the suitability of OSC for an application like this.

Also, don't make people buy your product to be able to interface with it. I don't know if there is already a suitable demo available, but it makes sense to have a full-featured version of the product with a full protocol implementation freely available for download. (Saving disabled or something like that.) This way someone who wants to try interfacing his DIY controller with your product can give it a shot, and you might end up gaining a customer.

[stryd_one]

Making a custom protocol is a double edged sword. On one hand it gives the greatest flexibility, but then again adopting an existing open protocol (Open Sound Control, for instance) could be a good option as well.

ultra's protocol is higher level than that. It would sit in the layer atop OSC, or in this case, MIDI.

Same concept as Mackie/LC.

[Guest julienb]

hi,

apc could be cool only for the rgb leds + buttons matrix

but for this point a *real full rgb leds + buttons AND open-source is here : http://unsped.blogspot.com/

indeed, there is no knobs.

but apc doesn't provide a lot of these ... not enough for me ;)

I lost time to experiment around monome to make my controller clip grid

with a java code (http://code.google.com/p/monome-pages/wiki/AbletonClipControlPage) it is very easy to control clips without max for live, or even without max/msp : only the monome, the java app, monomeserial router and Live (!)

so, I'm trying to go to the point on my post:

I'd like to began (and hope to finish...) a "monodeck like" OpenSource project.

by monodeck like, I just mean: buttons/knobs organized to control live easily.

midibox is definitively my choice

max for live will help, but without it, we already could do that.

who would like to begin the project with me ??

[julienvoirin]

who would like to begin the project with me ??

i am already working on it Julien Bayle ;)

[Guest julienb]

i am already working on it Julien Bayle ;)

do you have a website? a hub? a blog ?

at which point are you?

[stryd_one]

Plus ultra's goodies...

[ultra]

whenever i have time to work on it. 

[Mudo]

...

It is cool see how MFL developer get feedback.

It could be great Pure Data integration too not only for "closed" solutions. Max is quite expensive for "amateur" musicians... How much will be cost MFL?

...

[spazmatron]

I've been planning a midibox ableton foot controller for a while now.  Nothing fancy, basically just a clip matrix for my feet using midi notes mapped to clips.  My question is:  can I have both a foot (or any midi controller) and an apc40 triggering the same clips? 

For example: 

  The 1st button on the apc triggers track 1, clip 1.

  The 1st button on my midibox triggers the same clip.

The reason I ask, is that if I try this with 2 regular midi controllers, when I map a button, it overides the previous mapping.  Not to be confused with mapping one controller to multiple destinations.  I mean:  multiple controllers mapped to the same destination.  I'm hoping that perhaps the apc will keep its mapping even if another controller is mapped the same destinations.

Or perhaps this is already a simple problem that I just haven't figured out the solution to?

Let me know if this a retarded question.

Thanks