For people into this sort of thing, another option is using my foss Max extension, Scheme for Max, to script Live through the live API using Scheme.
https://www.youtube.com/watch?v=j0sKBA-Pv2c&t=1s
The live object model is MUCH nicer to use in a lisp, as basically you do everything by making dynamic lists to represent what you want to access! There are examples in the Scheme for Max help file.
(Also, Scheme for Max can run in the scheduler thread, unlike JS in Max. Though of course calls to the Live API are deferred to the lower priority thread anyway)
A couple of times I've tried somewhat seriously to build "google docs for ableton" (meaning two people editing the same project on different computers, seeing each other's edits in realtime). Frustratingly I decided it was impossible to do a really good job of it back then. This sounds like it might finally make it doable!
I've often felt as though the way to make a DAW that competes with Ableton today would be to build the entire UI around composable scripted modules.
Far too much of Ableton's secret sauce is hidden away behind Max for Live and top-tier pricing only features. This is a great step in the right direction.
Ableton and Max are totally separate codebases, and "Max for Live" is just a ~VST interface between them.
I do agree that "scriptable Ableton" would be far better for production and sound design than Max, because they make all the hard parts easy: MIDI, sequencing, mixing, etc.
In Max, you have to build everything from scratch, every time.
This is great to see. Not widely known, but it's already been possible to write Python extensions for Ableton using the LOM, which I was doing via ClyphXPro. But this looks easier!
Yeah, that was what got me into Live in the first place! Writing custom control surfaces in python from the reverse engineered stuff.
Nice to see they have put out options they will officially support though. I do admire that instead of saying "no you can't" they just said "we know those open python example scripts our there and we won't comment on them". :-)
With M4L you need to implement your feature in a device and add it to your project. My Ableton project template has a bunch of these on my main track. With extensions you use a context menu as the entry point which will hopefully be more lightweight. Hopefully they'll expose more of the object model over time and let us trigger these via keyboard/midi shortcuts.
For people into this sort of thing, another option is using my foss Max extension, Scheme for Max, to script Live through the live API using Scheme. https://www.youtube.com/watch?v=j0sKBA-Pv2c&t=1s
The live object model is MUCH nicer to use in a lisp, as basically you do everything by making dynamic lists to represent what you want to access! There are examples in the Scheme for Max help file.
(Also, Scheme for Max can run in the scheduler thread, unlike JS in Max. Though of course calls to the Live API are deferred to the lower priority thread anyway)
A couple of times I've tried somewhat seriously to build "google docs for ableton" (meaning two people editing the same project on different computers, seeing each other's edits in realtime). Frustratingly I decided it was impossible to do a really good job of it back then. This sounds like it might finally make it doable!
Don't kick yourself. It's not possible with Google Docs either. All these collaborative document editors have been mostly gimmicks/wastes of time.
I've often felt as though the way to make a DAW that competes with Ableton today would be to build the entire UI around composable scripted modules.
Far too much of Ableton's secret sauce is hidden away behind Max for Live and top-tier pricing only features. This is a great step in the right direction.
>Far too much of Ableton's secret sauce is hidden away behind Max for Live
The other way around. Ableton exposes some internal modules to Max for Live as Max for Live modules.
What Ableton gets from Max for Live is not internals, but basically a few Ableton-only Max-built plugins, that could as well use VST underneath.
There is zero "secret sauce" in max for live.
Ableton and Max are totally separate codebases, and "Max for Live" is just a ~VST interface between them.
I do agree that "scriptable Ableton" would be far better for production and sound design than Max, because they make all the hard parts easy: MIDI, sequencing, mixing, etc.
In Max, you have to build everything from scratch, every time.
i could see this being something that AI takes a bite out of in the coming years
i've been making my own vst instruments and effects with faust, and codex knocks it out of the park; it's basically a trivial task
the only problem is that i have to use software that's external to DAWs. it's only a matter of time before this is first class in DAWs
This is great to see. Not widely known, but it's already been possible to write Python extensions for Ableton using the LOM, which I was doing via ClyphXPro. But this looks easier!
Yeah, that was what got me into Live in the first place! Writing custom control surfaces in python from the reverse engineered stuff.
Nice to see they have put out options they will officially support though. I do admire that instead of saying "no you can't" they just said "we know those open python example scripts our there and we won't comment on them". :-)
>Extensions are built on the NodeJS platform, a free, open-source, cross-platform JavaScript runtime environment.
I applied for a job with them and proposed this exact thing about 8 years ago (got auto-rejected, I would've been very happy to work on it).
But I'm glad to see they finally did it.
You could already use Node through M4L. I'm not clear on what this adds that wasn't already possible.
With M4L you need to implement your feature in a device and add it to your project. My Ableton project template has a bunch of these on my main track. With extensions you use a context menu as the entry point which will hopefully be more lightweight. Hopefully they'll expose more of the object model over time and let us trigger these via keyboard/midi shortcuts.
They made extensions first class, chose JavaScript as the primary language, and chose node.js as its runtime.
Works for all tiers too