Ableton Extensions SDK
ableton.com170 points by bennett_dev 2 days ago
170 points by bennett_dev 2 days ago
I spent my day hacking on this to see what it’s capable of (built a simple little tool that displays MIDI clips as sheet music: https://github.com/madisonrickert/ableton-sheet-music-extens...)
My initial take on its strengths/weaknesses:
- Strong: Using the TS/JS ecosystem to render UI and tools
- Medium: Creating custom application windows in a web view. Window management features are pretty limited currently (can’t resize or render a native “close” button on the window chrome)
- Strong: Creating custom control panels for integrating with external services (like pushing and pulling audio clips or midi to/from an external service)
- Weak: Anything real-time, that’s still the domain of Max4Live or other control APIs, so don’t expect playback automation
- Medium: Tinkering with the Ableton project, clips, tracks, etc. API surface is still incomplete. Like I can read warp markers but not create them, for example. And I can’t access the global time signature settings.
The extensions are pretty aggressively sandboxed, and I appreciate that security consciousness in this season of the js ecosystem. It’s a hassle though if you want to save or load files outside of your little sandbox folder.
Thanks a bunch for the summary! Overall seems like a great start, very similar to how Figma got started, really aggressive sandboxing, then slowly they'll open it up as they explore the exact API surfaces.
Gotta say, slightly sad about the global time signature not being available to get/set, when I read about the new SDK yesterday my mind immediately jumped to bunch of use cases which all use the global time signature :P Oh well, I'm sure it'll be available in the future.
Thank you! If I’m reading your findings correctly, this is focused on UI capabilities, and likely rides on top of the existing Live Object Model (LOM) rather than a new integration.
Which is a bummer, because LOM is fantastic for what it does, but has many many many frustrating gaps. Like, it cannot add devices to the master/main track. It can’t read MIDI pitch bend events, etc.
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)
I need to check this out, I bounced off Max 3 times now because I find the GUI approach so tedious
Max itself can be manipulated through JavaScript. You can dynamically create and connect objects in it, set scheduler tasks, etc. Max goes a lot deeper than wiring some GUI boxes together.
Have a dig around here: https://docs.cycling74.com/apiref/js/
There's a big caveat there though that is widely misunderstood. Max has separate scheduler and UI threads. JS only runs in the UI thread, and thus cannot be used for reliable timing tasks - timing will seem to be ok until there is load and than the UI thread timing is out the window.
One of the main reasons I wrote Scheme for Max (S4M) was to enable tightly timed scripting. You can pick which thread an S4M instance runs in, and each instance is totally isolated, which is very different model from the Max js objects (including the new V8) one. Those are global and only in the UI thread. S4M works very well for this, I use it in Max for Live and can get it synchronized perfectly underload with other sequencers.
I started scripting max with JS and built Scheme for Max after banging into its limitations. My typical workflow is a mix of Max, Csound in Max, Gen and Scheme, with the fast majority of the work happening in Scheme.
Well, it's obviously not intended for realtime 'live coding', but as an answer to the problem of dealing with the GUI and manually cabling a patch up it suffices, though it does help to be fairly conversant with the basics of Max to begin with. For instance I've used JS to auto-populate a patch where the number of abstractions isn't known in advance and may need to change, with each abstraction then getting its own settings passed as generated arguments. It could be a nightmare cable spaghetti patch but JS made it end up very neat and tidy.
IMO there are far better options for realtime code-generated music. Max does what it does well, and shoehorning in interrupt level scheduling for scripting on top is out of scope for its remit.
Doing interrupt level scripting in it works just fine - lots of people have done it in C, C++, Scheme, and other extensions. I take it on stages and have produced music with it extensively. Scheme for Max is written using all the same C primitives from the Max SDK that the other Max sequencing options use and has been load and timing testing exhaustively.
I'm currently a PhD candidate in it, have previously used Csound, SuperCollider, Max, Pd, Common Music, and others, and have published/presented at conference on this topic. Of everything I've tried, I prefer working in Scheme in Max over other options. It is definitely practical and accurate. (Though in Scheme in Pd has soe nice features too!)
Can your external place objects and route cables around on the patch? That's the main thrust of my original comment, which is that JS scripting can help avoid having to patch lots of objects together in the GUI. Live scripting music is beyond the scope of my advice.
You specifically brought up "scheduling tasks". There is a JS task scheduler, but it comes with a caveat - the scheduled timing is accurate but the time of executing is not accurate because it runs in the UI thread. Hence my comment.
If you want to schedule tasks in Max accurately with code, you can either use Max, C extensions, or my extension.
yes, you can do patcher scripting from S4M as well as you can easily send messages to named objects, which is all you need in order to be able to do that. That is how max patching works - whether you do it in the GUI, JS, or messages to the patcher, the whole thing is just objects sending messages to other objects, and the patch is just a connected graph of references of instantiated objects. If you send message to a thispatcher object, you achieve the same thing under the hood as manipulating the GUI or going through JS. You can read about it if interested in the Max SDK documentation and in the Cipriani & Giri books on thispatching.
Somewhat unrelated, but the number of times I have invoked Ableton as a metaphor of challenging the status quo is quite high. I was a Cubase user before Ableton showed up and completely upended the DAW world. And they've kept going.
This is just what I've been looking for. I never warmed to Max for Live for mods. But the extensions SDK I can get behind.
Also the fact that Ableton has stayed independent (and bought Cycling '74, maker of Max/MSP) is IMO critical to their ongoing success...Compare to how Native Instruments and iZoptope are mere rent-seeking shadows of their founders' visions since PE/VC took over.
One of the features that got me hooked on Ableton Live was how easy it was to do "analog style" audio recording of whatever you're hearing in realtime...not bounce, render, or sample to another device (it can do all of these too). For the master bus - just create an audio track, arm for recording and set input to "Resampling". Can do the same with any number of tracks/groups. This is critical to me for capturing ideas in realtime and continually reprocessing/resampling as I go.
I was astonished when I first started making digital music 20 years ago that this isn't a standard feature in every DAW. Some DAWs (REAPER, Bitwig, AudioMulch) do this as easily, others (Logic, Reason) have workarounds.
Native Instruments is bankrupt, unfortunately.
They've been purchased.
Wow, you created Ardour! Thanks!
I was a heavy and loyal Cubase user then switched to Ardour when it came out because of OSS.
Also Reason, you guys remember Reason? It had such a warm, characteristic sound out of the box. You could easily hear it in many songs of the time; same with Fruity Loops but for all the wrong reasons, lol.
I don't do a lot of music at the moment, but it's nice to read you here ^^.
>Also Reason, you guys remember Reason? It had such a warm, characteristic sound out of the box. You could easily hear it in many songs of the time; same with Fruity Loops but for all the wrong reasons, lol.
Remember? It never went away. In fact, it was recently bought by LANDR, and just brought out version 14.
FabFilter is another independent company that make some of the best plugins around.
Totally unrelated, but it's still interesting that a lot of the key music software was / is created in either Berlin (Ableton, Native Instruments) or in / near Hamburg (Steinberg of Cubase — now owned by Yamaha — and Emagic of Logic — now owned by Apple). There must have been something in the air.
Partially a mix of strong, hacker culture in Germany in the 90ies + Berlin being a major place for electronic music in that decade.
For example, ableton was famousley co-created by the members of the monolake, a pioneer of minimalist techno in the 90ies. Some history there: https://www.roberthenke.com/interviews/ableton.html
Ableton yes - and Bitwig which is ex Ableton people.
But Cubase, Logic, etc weren't focused on electronic music in particular. They catered to general studio production.
Also NI, etc. was very linked to the scene from the early days.
Cubase, etc. have no such link that I know how, but there was still the strong hacker culture around atari and to a lesser degree amiga (vs PC), when PC was just not usable for anything low latency in mid 90ies.
I never knew that, and it is _really_ interesting! My DAW of choice (Bitwig) also based in Berlin...
I counter with Santa Cruz/Scotts Valley.
-Emu
-Plugin Alliance
-UAD
-Autotune
-Burl
I've used the same metaphor for AI tools. The incumbents keep adding features to the old paradigm (like Cubase did). Then someone comes along and rethinks the interaction model entirely (like Ableton with Session View). AI tools are in that transition moment right now — most are just adding AI to old workflows, not rethinking the workflow itself.
Wish we could get some native compatiblity with Linux. The closest I've gotten on NixOS was with Bitwig, with a simple compatability script I wrote: https://github.com/ArikRahman/Nixwig
Bitwig has native Linux builds though? Should be very easy, last time I tried it, it was literally click-and-play basically.
Ableton is another beast altogether, and I've also been trying to get it running for years at this point, no end in sight. Last time I tried, after being recommended https://github.com/BEEFY-JOE/AbletonLiveOnLinux (now sadly archived), I managed to get the actual UI to render and be interactive, but still couldn't get proper audio to work with my interface, only software rendered audio, so the quest continues...
Yes Bitwig is simple. Getting it to work on Nix took the slim layer I made.
No layer is needed. Bitwig is Linux native.
Yes I'm glad Bitwig 6 finally hit Nixpkgs making it truly natively reproducible and easy to use.
For the Push 3 standalone they have ported Live to Linux, but it’s confined to their own hardware.
> The challenges were many: we had to create an operating system, we needed to deal with porting Live to Linux, we needed to deal with all the gory details of WiFi and authorization.
I'd probably be ready to shell money for another studio license if they could just make that version available to us plebs that run Linux on our desktop computers. There is basically just 2-3 programs left to have running on Linux for me to finally be able to uninstall Windows, Ableton being one of them.
Bitwig 6 works out of the box on NixOS unstable.
I see it on Nixpkgs, excited to try it out. I hope Wayland compatiblity on tiling manager works, I had to use some workarounds previously.
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!
In the past, I've literally done screen-sharing for this, one "instructor" and one "pilot", basically like how you do remote pair programming typically, but with Ableton instead.
Besides that, Ableton themselves list a bunch of tools I assume works on some level, as they're listed in the help pages of Ableton: https://help.ableton.com/hc/en-us/articles/360012680119-Best...
Ha yeah I have considered the same. There’s not enough info exposed via the Python or Max APIs (or indeed this one) to sync all the state you’d care about so I think the only option would be syncing the actual als files (which are zipped XML) which means you’d only be able to sync at save points
We should talk - I'm building a new DAW with this in mind :)
We should talk - I’m building a Claude Code plugin for music composition and analysis, which currently integrates with Ableton using MCP and Ableton control surface (basically LOM) and an M4L patch. But it could easily work with any DAW that has the right primitives.
If you ever take another stab at it, would love to hear about it. me@hammyhavoc.com
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 use Nextcloud Office all the time with others. Prior to that, we used OneDrive/Office and Google Drive.
With tight deadlines, there frequently isn't the time to not be working concurrently on the same doc, especially when it comes to anything technical.
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.
I don't think it is true.
There are massive communities around tools far more simple than Ableton was even a decade ago, like SP404, Akai MPCs, Elektron Digitakt.
Many musicians treat any item as an instrument, not as a plaform. There are probably dozens of videos on youtube, where musicians explain, why they use more limited tools instead of Ableton.
To make a successful music tool (that includes DAW), you have to own a powerful workflow, that some group of musicians love or need. Extensibility is fine, but not the only way to succeed.
There are now people making music on pocket trackers that have ± same amount of features as modplug Tracker I used in the end of 90s.
The thing is, when you make a music with a guitar, you don't want your guitar to be 'built around composable scripted modules'. You want to play an instrument, and the UX should enable it, and generally get out of the way.
I believe that you misunderstood my message, which actually means that I didn't communicate well. Let me do better.
I am not proposing that someone needs to disrupt or make Ableton obsolete.
I am suggesting that the existence of Reaper strongly implies that there's an under-served demographic of people who (correctly) understand that the DAW can be more than a way to translate audio data from buffers to hard drive and VST host.
In the same way that there is currently a lot of innovation in mixers that don't just sum channels, it's not at all unreasonable to imagine that the DAW itself could be an instrument or at least provide composable functions that make other instruments more interesting.
https://www.youtube.com/watch?v=EclavOHIo4o
One of the best things about the golden age of music tools that we're experiencing is that guitars and guitarists have been decentered from the conversation. We don't call them guitar pedals anymore; they are effects pedals now. We're moving past the GROG TURN OVERDRIVE ON OR OFF phase into a much cooler place where pedals are usually MIDI controlled and often have CV inputs as well. Arguably the most lauded pedal of 2025 was the Polyend Mess, which literally allows sequencing of effects. It's awesome!
The cool thing about a truly composable modular DAW is that it doesn't have to get more complex. Being able to strip things down is also totally valid. Perhaps then folks wouldn't be making such a big deal about Tape:
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.
>Ableton and Max are totally separate codebases, and "Max for Live" is just a ~VST interface between them.
This is not strictly true, and Max for Live (M4L) is much more than a pseudo-VST. In the context of Live, the Max runtime is controlled by the DAW, which itself then exposes part of its interface to Max. So there's realtime bi-directional communication going on, more akin to how Propellerhead Software's (now deprecated) ReWire protocol used to work, the host passing control information (transport position, note data, etc.) and audio buffers into the client software and vice-versa. There is some superficial similarity with VST in this sense, but with M4L it's much more deeply integrated into the DAW as a whole. The Live Object Model[1], while not complete, is extensive, and there is very little that is off-limits to a M4L device to manipulate, with the caveat that care must be taken to avoid overflow of the control stream coming back from Max into Live (certain operations must be placed in the low-priority scheduler thread).
This new API gives much of the same control that M4L already did, but without having to have Max involved.
>In Max, you have to build everything from scratch, every time.
Again, not strictly true. Editing a M4L device opens the full Max environment, which has a snippets[2] feature much like any other good IDE. You can easily build a large library of boilerplate code for your own specific purposes with it. There are also many basic examples included out of the box.
I think we're talking past each other.
I don't own Max for Live. If I want to use it, I either need to upgrade to Ableton Suite for $500 or I need to upgrade to Standard and buy Max for Live separately (also $500).
There's a huge ecosystem of tools that are implemented as Max for Live packages which I cannot access because I haven't paid the toll.
I see that even this new Extensions SDK is only available to people who have paid for the full Suite edition.
I'd describe that as a market opportunity.
FWIW you should be "able to" get 2ndhand Ableton Suite licenses for significantly less...IIRC I paid ~$350 a few years ago.
They also offer substantial discounts if you attend their seminars. I was able to buy Live Standard for roughly 150€ a few years ago.
Please say more
Yeah. How does ableton handle the transfer? Do you mail them the transfer request, they generate a new key and mail it to the new owner?
They describe it here: https://help.ableton.com/hc/en-us/articles/209771405-Buying-...
You're describing reaper. Super great for scripting
Cool! I'll check it out.
Well, you're also describing Ardour (with the proviso that we don't allow scripts to much on the GUI side of things). Access to the "object model" from Lua is extremely wide-ranging, and since Ardour itself is open source, you can add whatever other access you need or want rather easily.
>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.
I answered this in a different branch of the thread, but you're kind of missing my point. I don't own Max for Live, so the large ecosystem of useful tools that I'd enjoy trying out is unavailable to me.
It's not about special powers, just being forced to pay the gatekeeper to the otherwise free/OSS ecosystem.
>I don't own Max for Live, so the large ecosystem of useful tools that I'd enjoy trying out is unavailable to me.
Well, it's not that difficult to purchase as an update to Suite or by itself, on a typical western salary.
The ecosystem has tons of free/open source devices. Is it that bad that Ableton doesn't make Max (which they had to buy the whole company for) free too?
I prefer they have actual product revenue like that, and don't go the VC route, gifting stuff to get market share, and then coasting and rent-seeking like NI and others.
Max/MSP has always been a paid tool. There was never a situation when you were going to be able to participate without paying.
This sounds a little like you're complaining that you cannot watch all of the free Youtube content because you don't want to pay for the device that will display it.
That is... not a good analogy at all.
What it is, though, is a misguided attempt to move the goal posts on what I actually said, which is that a huge amount of the value of Ableton is gatekept behind paid addons.
If a DAW was structured like Blender or KiCAD and designed from the ground up to be extensible (or minimal!) then you wouldn't have any impetus to try to shame people who haven't paid a gate toll to execute software people have contributed to the public domain.
Agreed. It's not a great analogy.
I'm annoyed because you keep referring to the cost of a license as "gate-keeping" or somehow "hiding away" your ability to use the software. Pay the cost for a license or don't. It's a reasonable price for the tools.
> I don't own Max for Live, so the large ecosystem of useful tools that I'd enjoy trying out is unavailable to me. t's not about special powers, just being forced to pay the gatekeeper to the otherwise free/OSS ecosystem.
You seem mistaken about Max/MSP being free or open source, which it has never been. Certainly not in the last eighteen years since I've been using it.
You seem to be saying that it would be a whole lot nicer if Ableton were an open source tool that we didn't have to pay for and could develop ourselves. Maybe that WOULD be an improvement in some ways. It would at least be free. A lot of things might be better. Some things not so much.
But it's not. Live is a paid product. And so is Max/MSP. And I'm very happy to continue paying these developers to keep doing a great job because they make tools that are tremendously helpful to me and they don't abuse that relationship with things like monthly subscriptions or unreasonable restrictions. In many ways Ableton is a model company that is self-governed and largely free of outside influence like private equity. I want them to succeed and I want more companies like them to thrive.
-----
There is a free and open-sourced alternative to Max/MSP: Pure Data. If you think open-sourcing this type of software is such a great idea, then you should develop in Pure Data instead of Max/MSP. There are probably open-sourced DAW projects out there too that you can integrate into as well.
Maybe then you'll realize that Live and Max/MSP's asking price is not so high after all.
That's actually exactly what I do! And I highly recommend it as a viable alternative to Max/MSP. It's the native way to create patches for the Organelle and many other instruments.
PlugData in particular has been a real joy to play around with.
I'm glad that your tools are working out well for you. I do reject the idea that I should STFU about being annoyed that I can't run Max for Live scripts, though. Native Instruments Kontakt isn't my favourite piece of software (or company) but at least they understood from early on that making the player free drastically increases the value of a paid license for the people who make content on that platform.
It's 2026. I'd hoped that we were well past needing to debate whether OSS is good or not. Apparently we're not!
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
IMO it’s going to work the other way around. I’m doing my best composition ever using LLM coding tools that just use Ableton as a rendering engine.
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". :-)
This is cool - feels great that there's a growing long-term incentive to implement open SDKs and APIs, for the sake of agent-forward prosumers, in the spirit of earlier internet stuff that used to do it but stopped.
Yes! Glad to see someone else having this thought. Will be interesting to see how it plays out
The have it buried in the FAQ, but that's pretty much the interface for AI. And a really good one. You can use it with just your old human intelligence, but then you can also get help if coding isn't your thing.
Biggest issue with having something so easy to work with is the huge amount of extensions we will be getting, which makes it harder to find the jewels.
Also wondering if we will get extensions for Abelton Move as well. There are already a couple of hacks that are adding functions that are running as a sidecar. This could give them an official API.
>The have it buried in the FAQ, but that's pretty much the interface for AI.
Well, they have it buried because it's not "the interface for AI", it's a programming interface, that could have existed 5 and 10 years ago, pre-AI. And in other DAWs, it did.
It just happens that a programmatic interface is also very usable as an AI target. But that's orthogonal.
Yes of course. But then they wouldn’t be the first to create APIs, SDKs or CLIs as an enabler, because of AI. Which is why I‘m even more happy that it isn’t just a MCP.
Got some links to the Move hacks?
Answering my own question: schwung.dev
Also: yes, this SDK is a great interface for AI. It was trivial for Claude to quickly write a MCP extension. There is a lot of room to open up the API more and to save on tokens, but I already had fun sketching out new songs or open older projects with clips in session view and just tell Claude "create an arrangement out of them".
Yes Schwung is now the best. There is also the extending-move repo on github which has some documentation in the wiki. From time to time I look into the Abelton move reddit.
I've been experimenting with controlling Ableton with VR gestures. It's amazing how quickly I made a prototype using IWSDK and AbletonOSC.
Time to see what's possible with the new SDK.
Among the first examples they show Paulstretch for Live. I remember using Audacity to apply it in the past because it wasn't easily available in other DAWs :)
Try slowing the PSX opening sound by 5x to 10x, you won't regret it.
>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.
I would imagine nearly every programmer who has ever used a DAW has thought “this would be cool to have its own scripting language.”
They already had Python. Mentioning an architecturally obvious idea in a job application is likely to read as insulting, because it presumes their engineers weren’t already aware of that possibility.
> Mentioning an architecturally obvious idea in a job application is likely to read as insulting, because it presumes their engineers weren’t already aware of that possibility.
That's a bit much no, why would it be insulting? "Great minds think alike" would be my reaction, instead of "Ew, duh, of course we thought of that, you think we stupid?".
I'd love to read those cover letters then.
Then I can make a meaningful comparison.
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.
M4L is basically a plugin sdk. It loads as a VST would (roughly), just with access to Ableton UI elements.
Ableton Extentions if a first class api to Live, kind of like AppleScript.
I hate max so much. I wish this could extend to the push 3, I've been working on an orchid clone.
It would be TRIVIAL in any other language, but noooo, I have to write a fucking max patch and deal with their trash visual syntax and runtime.
FWIW you can bypass quite a lot of the Max visual stuff by using the JS support, which now finally supports modern JS (the v8 object). A lot of the LOM (Live API) is exposed there though you will no doubt need to use Max objects for some stuff. They also have web UI support with jweb.
I get the frustration coming to Max as a regular developer, but actually when I bothered to learn it was one of the most rewarding uses of time and I find it really quite fun to work in (and frustrating sometimes of course! But the JS support helps). You just need to forget everything you know about programming lol
The visual patching part of Max makes sense when you know the history of the program. It was built for musicians working at the forefront of interfacing MIDI with the power of the more compact mainframe computers of the day (PDP-11 IIRC). The 'programming' was done through a GUI running on the first Macintosh. At first there was no audio processing in Max itself, it was purely for generating and manipulating MIDI data.
You can see this 'bare-bones' style of Max with Miller Puckette's continuation of his original work in Pure Data[1] (aka Pd). The nice thing about Pd is that it's open source, so all the scheduling and signal flow logic can be examined and understood. As I understand it, the basics of Pd are comparable to how Max still works under the hood, though no doubt there has been some deviation over the years.
As it is now, Max offers a very smooth interface to the basic paradigm that was established 40 years ago, with many modern advances, but the fundamental idea hasn't changed all that much since it first came out.
If you really hate having to work through a GUI for computer music there's always SuperCollider[2] and its many derivatives (Sonic Pi, TidalCycles, etc.). It's nice to have options!
[flagged]
Woot, javascript in live, now we can have supply chain attacks in our daws; yay.