There’s not much to say about this news: if it’s the kind of thing you’ve been anxiously awaiting, you’ll know you’re in luck just from the screenshots.

First, for anyone with a recent MacBook and a copy of Max for Live, Juan Pablo Carrascal has come up with a lovely solution for on-the-go production. Using the trackpad’s multitouch input support, his Max patch transforms your laptop into a MIDI control device, for those times when you don’t have a controller handy. (See also a great, open source Mac touchpad tool.) I don’t have a compatible Mac on which to test this, but it looks great. And because it is a Max for Live patch, you could use this as a basis for other, similar tools.

Juan Pablo writes a detailed look at how he put the patch together and how to use it:

Macbook trackpad as controller for Ableton Live (with Max for Live)

You just need an external mouse, since this will take over the use of your trackpad. It could also be handy for adding an extra touch controller in a live performance (especially in cramped performance spaces).

Second, for Max for Live developers, Peter aka ShelLuser on the Live forums has come up with a patch entitled LOM.Navigator that gives you full access to every single function provided by Live’s internal control surface support. It’d be nice if Ableton had designed that control surface object in a more logical, consistent way, or properly documented it. (ahem) But Live hacker to the rescue: LOM.Navigator lets you explore all the capabilities Max for Live can control, opening up lots of possibilities for live performance. Full message thread:

LOM.Navigator v1.0 – With *full* control surface support. [Ableton forum; thanks, Mudo!]

  • Seppe

    I wonder how Ableton feels about people hacking the control surface functionality. I dare to hope that they acknowledge to have been beaten by their user community and make easy to use control surface functionality as a feature of Live 9. But then again they could also change the whole library and make all earlier scripts useless…

  • http://www.createdigitalmusic.com Peter Kirn

    I've never gotten the impression that Ableton had a desire to actively block hacks to their library. There's no official word beyond that, but that's what they've said. They could change the library and make things break, yes; not intentionally, but because of other changes. So that is a danger.

  • http://aumhaa.blogspot.com amounra

    I honestly don't think they have a stake in it….but I imagine if some core functionality in Live gets changed for 9 (like many are asking for) then some of the existing Python interface may change as well. Too much of the existing implementation rests on what has already been written…they aren't going to do a complete rewrite.

  • http://www.createdigitalmusic.com Peter Kirn

    Well, yes, what I will say is that Ableton (both Gerhard and Robert, I believe) were on record *before* the release of Max for Live with concerns that a scripting API could cause third-party development to break between releases. ;) And that's always a challenge.

    Honestly, I wouldn't mind personally seeing functionality break if the API for control surfaces were improved in the process – see complaints in the thread above. And so that's natural; you expect some change and a benefit as a result. The big question to me is, as I understand it, a lot of people would like to see a more complete, better-documented, clearer control surface API. Given that Live remains the dominant choice for live performance, and control of the software is essential to performance, I think there's always going to be room for improvement there. It's fundamental to the software.

  • http://aumhaa.blogspot.com amounra

    I think a lot of the reason that the "control_surfaces" have remained undocumented are that there just simply isn't much to document. There are a few things that you can do with the _Framework scripts (enabling/disabling components, sending/recieving messages directly from a connected controller), and basically nothing with older scripts (e.g. MCU, RemoteSL, neither of which have named assets in their scripts). I look forward to some revisions in these areas…and quite frankly, if they don't emerge I'll write in the functionality myself. It has been a huge complaint of mine that this was missing from the initial release, but after delving into the _Framework scripts over the last several weeks, I understand why it is missing. There simply aren't enough available hooks in the _Framework scripts to do much via m4l the way they currently are.

    Hopefully Cycling/Abes have made some time for this…using Python for scripting API methods is much faster and more stable than any of the other current alternatives, and being able to bridge that to Max (or js within Max) opens a lot of possibilities. It is VERY unfortunate that they have not made the Python API public, but I can understand a lot of reasons for this to be the case.

    I'm with you: break it if you must, as long as it means more/better functionality in the long run. But it would be nice if we could see why things were breaking each time (without the months or longer wait for someone to come up with copies of the decompyled scripts).

  • Charles

    The original press releases promised that you'd be able to customize your APC-40 using Max4Live – in fact the ableton.com webpage for the APC still claims "With Ableton's Max for Live you can customize your APC40", which is only barely true. In fact, there is NO provided facility for customizing the APC-40 controls using M4L or anything else. Instead there's some thin and cryptic documentation about the control_surface part of the Live Object Model, and if you dig around in the forums you can find suggestions for how you might begin to go about rerouting your APC's incoming messages, but it's only the faintest improvement over the old method of hacking the API using Python – now you have some official documentation at least, and you can use Javascript instead of Python. But frankly you'd be better off using Bomes or, better yet, just buying a Novation controller which comes with software for assigning the knobs and buttons to different operations. This little bit of ball-dropping is one of the reasons I have yet to bother to buy Max For Live, despite owning both of the parent programs and participating in the beta program. Here it is nearly a year later and there's been no improvement in the situation. I understand that these are small companies with limited resources – but (a) Akai does not have that excuse and (b) I also understand that you shouldn't make promises you can't keep.

    I'm hoping the LOM.Navigator will indeed allow me to "explore all the capabilities Max for Live can control" – but it looks to me like it's purely an informational tool (albeit a very nice one). Since I don't have M4L I can't verify this myself, but I am prepared for disappointment.

  • browneye

    I'd always thought they were going to allow M4L to be attached to an input device instead of per track. This would allow M4L to see all the data before Live and control surface scripts see it. Perhaps the ability to add M4L at the preferences.midi page is the simple but critical missing part.

  • http://thestudiosessions.co.uk Darren E Cowley

    @Charles,

    I beg to differ…..

    http://thestudiosessions.co.uk

    I can disable and enable pretty much everything on the APC and set up scene upon scene of functionality within M4L….

    Then there's the MSP side of Max so you can do all sorts of stuff with the audio, as you have Max already i'm sure your more informed than i am in this area but the abilty to control all from the APC is surely tempting??

    @Browneye

    Yes you can see all of the control surface elements before Ableton, if you turn them off then you can reroute anything you like, and even deal with multiple devices in the same device if you code it as such…

    Now i'm off to look at the Apple magic trackpad!!

    Cheers

    D

  • http://trash80.net trash80

    A few things here…

    Using the trackpad for a live control surface is a bad idea at least it was for me. My last gig I ended up having to perform a track which my live set was not setup for. A drop of sweat hit the track pad and made it functionally useless, it was a nightmare- I ened up having to stop the music to clean it off- This is also the reason some other touch surfaces fail in a live setting- like Stanton's Da Scratch.

    On the API: I would say if they broke Python scripts in a later Ableton release, but added a option for a debug window or had automatic python crash log- I for one, would not complain. Fixing my scripts would be easier than debugging new additions to my code when they break.

  • http://www.ilektron.com Mudo

    If anyone is interested I'm learning python for hack LiveApi to use with my Octinct RGB and I have a lot of info to share.

    As a legal user I will love the release of the clear documentation and help files. It is the other side of the OPEN HARDWARE thread… corps getting closed and people going hack.

    At last co-existance is possible and necessary.

    jm2c.

  • Charles

    Darren: how long did it take you to build that yourself?

    You yourself said here almost a year ago: "The pricing wise is amazing to consider what it can do for you, but when you only see limited usage for example the customization of the APC we were promised is possible from M4L (i’m sure it is but it seems a long way away after using the beta for the last month) then it’s a steep price to pay for what should have been included in the purchase price of an albeit expensive controller (the korg nano series has more flexibility from a £50 device!)"

    Without the efforts of people like you and a couple others there would be *no* APC customization. It's great that you guys have picked up the ball, but that doesn't change the fact that it was dropped in the first place. M4L should have shipped with the equivalent of what you and ShelLuser and s4racen (and whomever else I'm forgetting) have busted your asses to put together over the last year. I'm well aware that Max is a DIY environment – I've been using it since 1992 – but there's a huge difference between "we've included a tool to let you manage messages to and from the APC" and "we've included some cryptic documentation and a couple general objects that are one step away from scripting and if you do some reverse engineering and read a lot of forum threads and spend several months working on it you may be able to decipher a way to reconfigure the APC that's effectively identical to hacking controller scripts but at least has a nicer UI." If I wanted to go through that headache (or wait for you to do it for me) I could have used Python or Bomes instead.

    Hell, it was always *possible* to break out the C compiler and create a control surface customization object from scratch even before M4L came along. The degree of assistance actually provided out of the box was feeble. They should not have said anything about M4L allowing you to reconfigure the APC, given what they actually shipped with.

    And your very own D1sabler patcher itself says "This disables all clip stop buttons but as yet no way of enabling them" – so after almost a year and a lot of volunteer work we STILL don't have complete control of the APC.

  • lematt

    ableton has been really disappointing with the documentation of Max4Live.

    they often are disappointing that said…

  • http://thestudiosessions.co.uk Darren E Cowley

    “we’ve included a tool to let you manage messages to and from the APC” and “we’ve included some cryptic documentation and a couple general objects that are one step away from scripting and if you do some reverse engineering and read a lot of forum threads and spend several months working on it you may be able to decipher a way to reconfigure the APC that’s effectively identical to hacking controller scripts but at least has a nicer UI.”

    LOL….

    My point was it is possible….! but i concede your point!

    Comparing it to the korg nano now in my eyes was naive, i learn from my mistakes as they say…..

    The challenge is that the APC40 was written for before M4L came along so i don't think anyone envisaged what a pandoras box it would be when we got access inside it, some of the controls are logical eg. you can turn them on or off, but others work as pairs (previous and next device buttons) which take a couple of id's to re-enable which is weird because you can only have them both off or on…. Then there's the group controls like the Button Matrix, Scene Launch buttons which are a turn off and reprogram to do other things as you can't turn the control surface actions back on….

    That said there's nothing in the control surfaces that can't be re-written in M4L, for example i turn the Scene Launch buttons off and then handle the scene launch functionality within M4L rather than through the control surface scripting….

    For me what's missing from the documentation is the formatting of the messages that each element needs, we know what the functions are, they've been available from launch through the API.Explorer, but we don't know what the calls syntax is. I've worked out many of them through trial and error and have had some help when i've headed down an avenue that can't be solved currently!

    Cheers

    D

  • http://www.jpcarrascal.com JP

    Now updated and improved!

    - CNMAT OSC patches not necessary anymore

    - New 6-pad drum trigger control

    http://blog.jpcarrascal.com/2011/01/touchpad-cont