Magenta Studio: machine learning music tools inside Ableton Live

Five plugins in one Max for Live device

Magenta Studio is a set of plugins contained in a Max for Live device, and the whole set ships as a single artefact. This repo is where the code to Magenta Studio is maintained, while information, support, and installation instructions for the tools themselves live on the project website at magenta.tensorflow.org/studio. The repository also states plainly that this is not a Google product.

The primary language is JavaScript, and the architecture is unusual enough to be worth describing precisely, because it explains most of the setup steps.

All of the plugins are contained in a single web application that runs in the Max environment via Chromium Embedded Framework, or CEF. The front-end code is all in the client/ folder, which contains the five plugins along with common UI and communication components in client/components/. Those objects are built using lit, the lightweight web components library.

So the plugin you see in Ableton is not a Max object drawing its own interface. It is a web page, rendered by an embedded Chromium, hosted inside a Max for Live device. That choice is what makes modern front-end tooling usable, and it is also why the build is a webpack build and why a local web server is part of the picture.

The project is Apache-2.0 licensed with a 2023 Google Inc. copyright, the home page is g.co/magenta/studio, and the last push to the repository was on 2026-06-19. The published release history has one entry, v2.0.0 from 2023-08-24, so the tag is a version marker rather than a release cadence.

The Express server and the port that matters

The communication between the web application and Live is handed through Max, and the mechanism is a local Express server that runs on port 3333, or 3334, 3335, and so on if you have multiple instances open.

The port detail is not incidental, and it is the single most likely thing to confuse someone working on this. Max for Live devices are hosted by a Max runtime, and a Max patch can run more than one instance. Each instance needs its own server, so the second instance takes the next port. The documentation repeats the pattern consistently, telling you to open the app in the jweb object in Max or load it in the browser at http://localhost:3333, again 3334, 3335, and so on if there are multiple instances running.

That is a genuinely useful development affordance. You can iterate on the interface in a browser with the browser dev tools, pointed at the live server, while Max handles the audio side. The interface is a web application, so the dev tools are the dev tools you already know.

The Max patch and the related JavaScript files live in the folder called magenta4live.amxd/. The amxd extension is what makes the folder a Max package, and it is the same folder that ends up inside the exported device, since the build puts all of the modules into magenta4live.amxd/code/public.

The server itself runs on Node for Max, the Node runtime for Max patches described in the linked Cycling '74 introduction, and the README links to the introduction article for it.

Installing, and the model download that happens behind your back

Installation is one command, and the environment requirement is specific: tested with Node LTS v18.12.1, and the package manifest declares the engines field as node ~18.

npm install

What makes that command more than a dependency install is the postinstall script. The manifest runs npm run download:models as part of postinstall, and then changes directory into magenta4live.amxd and runs npm install there. So an install pulls the machine learning model files and installs the dependencies of the Max package, not just the front-end dependencies.

The model download is a separate script, scripts/download_models, exposed as its own npm script as well, so it can be re-run on its own if a download fails. The models are what the plugins actually do the work with, and they are not in the repository.

That design has a consequence for anyone deploying the plugin on a locked-down machine. The npm install is not hermetic, because it reaches out to fetch model files. If the download fails, the plugin will not work, and the failure will look like a missing model rather than a broken install. Re-running the download script is the first thing to try.

The runtime dependencies list is also worth a glance, because it shows what the plugins are built on. Alongside the lit and chroma-js front-end libraries, the manifest carries the Magenta music packages, and the build tooling is webpack 5 with babel, sass, and the usual loader set.

The development loop and the build to device

There are two webpack modes and they map to the two tasks you care about.

For development, npm run watch runs webpack in watch mode with the development environment, and the documentation says this rebuilds the app when changes are made. You then open the Max project to start the express server so you can test your changes, either in the jweb object in Max or in the browser at the local port. The one caveat the documentation states is that hot reloading is not enabled, so you need to refresh to see changes.

That caveat is a small but real friction point in the loop, and it is a consequence of the CEF architecture. There is no injected reload hook into the embedded browser, so a rebuild is not automatically reflected in the running device.

For a device build, npm run build runs webpack in production mode, and all of the build files are placed into the folder magenta4live.amxd/code/public. After that the export is done from Max itself: open the Max project, then select File > Export Max for Live Device..., and then select a location to save the device. Once the dialog closes, the device has been built.

So the build has two halves, one in the terminal and one in the Max GUI, and they cannot be merged into a single command without automating the Max export.

There is one manual finishing step the documentation is unusually specific about, which is replacing the icon of the magenta4live device. On Mac the sequence is to open the Magenta icon in client/magenta_logo in Preview, select Edit > Copy, right click on magenta4live.amxd and select Get Info, select the tiny icon in the upper left of that window, and select Edit > Paste or enter Command + V. It is a five step manual operation, and the documentation lists it as numbered steps because there is no script for it.

The version number in the root package.json is what appears in the About dialog, so that is where you change it when you cut a new version.

What the design buys, and what it costs

The CEF-in-Max architecture is the whole design, and it has consequences in both directions.

What it buys is a modern front end. The plugins are lit web components, so the UI is built with the same tooling as any other web application, with a component model, with npm packages available for colour manipulation and layout, and with browser dev tools available during development. The dependency list makes that concrete, with lit at version 2, chroma-js for colour work, navigo for routing, whatwg-fetch for the fetch polyfill, and throttle-debounce for event handling. None of that is available in the Max environment itself.

What it costs is a Node runtime, a local server, and an embedded browser. Every plugin instance runs a web server on a port. The device is not self-contained in the way a classic Max for Live device is, since it depends on Node for Max, and the model files have to be fetched. For a plugin you use once in a session, that is a lot of machinery.

The comparison with a native plugin is the honest alternative. A Max object with a drawn interface has no server, no Node dependency, and no port to think about, and it is the right approach for an instrument with a handful of controls. The trade is that you are limited to what Max can draw, and the moment the interface has text input, a scrolling list, a rich colour picker, or a display that would benefit from a real layout engine, the web approach wins on capability.

The comparison with a standalone web application is the third option, and it is worth noting that the package description says the plugins are provided as standalone applications and for Ableton Live. The same front end that runs inside the device can run on its own, and the Express server on port 3333 is that path. A standalone version avoids the Max runtime entirely, at the cost of losing the direct connection to the audio session.

Editorial conclusion

Adopt Magenta Studio if you use Ableton Live and want generative music tooling in the same session as the rest of your project, and if you are comfortable with Node and a Max for Live device. Do not adopt it as a standalone production tool without checking the version support, since the release history stops at v2.0.0 from 2023 and the last push is from June 2026. Verify first that the model download step succeeds on your machine, because that is where the first run fails if the network or the platform is not cooperating.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. magenta/magenta-studio on GitHub
3. Project website
4. README
5. Releases