The Living Thing / Notebooks : Ableton live

Pro tips

Scripting live

One of very few officially supported scripting languages for any DAW is Max for Live, for Ableton Live [1]. It’s a pity, then, that it’s awful. There is an alternative semi-supported “back door” via LiveOSC. Ins and outs of both will be discussed here.

You could instead use a non-mainstream DAW. These often do have scripting languages. Notably, the audio production environment Renoise has embedded scripting using the respectable scripting language lua, although Renoise itself is a freaky non-mainstream sort of tool. csound also comes with some hybrid DAW/IDE options. There are probably other hacks available to the bloody-minded. See audio software.

If you care about nothing but tempo you can use the open Ableton Link to synchronise arbitrary things.

Build your own plugins

This is the best option; there are many audio frameworks/languages that do this, such as csound, faust, Juce/c++, and so on. However, these lack the ability to control Ableton back; the control flow is mostly one-way. Even, e.g. synchronizing with the host can be harder.

So, let’s say you really want to automate Ableton in some new and exciting ways.

Max for live

Max4live is API accessed only through a clunky “arty codey” quasi programming language MaxMSP, whose chief selling point is that it is probably Turing complete. Although if Alan Turing’s had modeled his famous Universal Machine off MaxMSP, the paper tape would have been on fire.

Worthy usages

  • sync with supercollider: atk.scsync handles tempo-syncing with supercollider. You can use Jack to plug the two together, and ignore the worst of Ableton.
  • Sebastian Tomczak is a patient saint who creates wonderfully simple hacks using Max and Live, probably hundreds by now, and they all do simple but wonderful things that do not involve butting against the limitations of the platform.

Javascript in Max4Live

You can try to access MaxMSP’s patcher interface using javascript. I’m not a fan, because MaxMSP is horrid, and the API design is inconsistent and buggy. It’s a bad API wrapped in a bad language, which kind of removes the labour saving potential of the interface. An oft-made comparison for accessing things with APIs is that it is barrier contraceptives for sex. The loss of intimacy and convenience is real; but then, the trade-off is worth it for the safety, and you can still do most things you want to do, plus some things it would be dangerous to do any other way.

If that is so, using the Live API through Max for Live’s Javascript API is like first putting a condom on, say, your penis, then putting a gutted chicken carcass on that condom, then attempting penetrative sex, in that… You know what? In just about every way it is like that. I’m not breaking it down further for you.

Anyway, I use the in-built javascript interpreter for MaxMSP in Live, because having to wire patch-cords is depressing, and because Java has no access to the Live API.

On the plus side, the API is rich - you can do DSP and MIDI inside Ableton. It’s also officially supported by the manufacturer. Moreover, Max for Live does have a lot of market-share and hence a lot of community around it, which makes up for a many evils. Then again, there are other fetishes for putting weird things on penis that likely have an even larger community, and lots of those have more entertaining failure modes if you do them on stage.

Anyway, we push on.

But mark ye; avoid the following mistakes, for I have already made them for you, and shy from the following horrible flaws, lest ye be disappointed.

  • It is slow. Accessing the names and values of 191 parameters on my 2.5Ghz machine takes 116ms. That’s 1.5 million CPU cycles to read each 8 byte float. I know that javascript is not a performant language, but that’s some special awfulness.
  • The version of Javascript (1.6) is elderly beyond belief in computing terms. JS 1.6 shipped in Mozilla 1.5 in 2005. That’s right, the same year that Youtube started. The performance and usability improvements in JS versions since then have been enormous, but MaxMSP sidestepped coyly around them.
  • String values are returned with quotes in the string. Set the value of a LiveAPI path and then get it back again. You’ll find it is still a string has decorative quotes stuck it, which you then have to remove before you do parse it, or even submit it to the same API again. Why? Who will ever be made a happier person by this?
  • Float values are returned as some kind of object which looks like a number, but fails if you do arithmetic. So you have to cast your float return values to floats to use them. Maybe they are strings? Who knows? The docs don’t. And anyway, why would an internal API only return strings? The simplest explanation I have is that it is always returning me strings then sloppily casting them to floats sometimes, but why the hell would a high-performance DSP program handle floats by casting them to strings sporadically when reading values? The mind quails; I will pretend it is not so. I guess the quotes are there to tell you that the API looks typed, but is JSON, merely to rub in how it would have been no harder for them to expose it as an open web service, but they didn’t because they want to shamelessly up-sell you, and are reveling in that fact.
  • There are a million tiny mistakes to indicate that it’s half-baked, and few enough fixes to indicate that they don’t really care. Pertinent example: The system to attach mouseover help-strings to javascript outlets causes segfaults if you use it at all. Not the most exotic use case for mouseover help strings, mousing over them I mean. I reported it in November, [2] but no fix has been pushed. I wouldn’t mind this if it were an isolated incident, but there are so many segfault-causing bugs that you kind of get bored, so I’ll use that as an example and move one. The most irritating response I’ve got about that is that it’s fixed in the “new version”, which costs 150 bucks. Their mistake, my cost. Cool. I should, I presume, learn from this that other basic functionality I require will be so rudely delivered.
  • Lots of details are just badly thought out. Such as:
    • the native format of patchers in MaxMSP is JSON, but in an unannounced, undocumented move for unspecified reasons, they disabled “eval”, so you can’t read JSON from Javascript. I mean, you could, if you loaded up a JSON-reading library. But that would require you to be able to eval the contents of the library file.
    • throwing errors doesn’t do anything useful. Try it out.
[1]Were it not for Max For Live, there would be no scriptable mainstream audio production tools at all. This, in an age when even word-processors have macros. I could draw comparison with the degree of repetitiveness in modern techno and in modern bureaucracy that this implies, but that would be petty. Anyway, it means more jobs in techno that have not yet been automated away.
[2]wrote that in 2013, haven’t checked it since then. Based on experience, even if this bug is gone, it will have been replaced by others equally dire.


The alternative. LiveOSC is really poorly documented, but definitely a real thing, and far and away the most convenient way to access Live. It doesn’t have DSP access, and it doesn’t have official recognition. It doesn’t even have good documentation or a github repo. However, it is used by cognoscenti-types and is genuinely well-designed, or at least doesn’t actively try to piss you off. LiveOSC is a python based interface using the private “control surface” python API to access Ableton over OpenSoundControl as a server. It is based in turn upon LiveAPI, which avoided the network layer but was more fragile and python-specific. pylive uses LiveOSC to control Ableton from a python client and thereby comes full circle. Thanks Daniel Jones for a tidy bit of work there. (Don’t be confused; there are two separate python with blandly generic names working together here, but they are completely different.) You can also use LiveOSC with other interfaces, such as Livecontrol 2.

LiveOSC source is here, and livecontrol2 source is here, although I can’t find an actual download link for either. pylive is, by the way, dependent upon pyliblo, although they haven’t gotten around to documenting that yet.