# Magenta RealTime 2 streams only on Apple Silicon, and vendors a library it plans to drop

> Magenta RealTime 2 is Google's open-weights live music model, shipped with a Python library for JAX and MLX, a C++ streaming engine for MacBooks, and a set of example applications including an AUv3 plugin. The parts worth reading are the hardware table, which splits the chip list in two, and the packaging metadata, which carries an explicit note about vendoring a dependency as a submodule until it reaches PyPI.

**magenta/magenta-realtime** — Magenta RealTime 2: An Open-Weights Live Music Model

- Repository: https://github.com/magenta/magenta-realtime
- Website: https://magenta.withgoogle.com/magenta-realtime-2
- Stars: 1,812 · Forks: 201
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/magenta-magenta-realtime

## Real-time streaming is Apple Silicon only, and the chip table splits the two sizes

The hardware section draws a hard line and then draws a second one inside it. Real-time streaming, meaning generating audio faster than playback, requires Apple Silicon, and two model sizes are offered. mrt2_small at 230M parameters runs in real time on any Apple Silicon Mac including the Air models, while mrt2_base at 2.4B parameters gives higher quality and needs a Pro Max chip. The table makes the boundary explicit: the M5, M3 and M2 Max chips and the M4 Pro carry both models, while the M2 Pro, the M1 Pro and every Air row in the list, including the M4, M3 and M1, are marked for the small model only. So the deciding question is not simply whether the machine is Apple Silicon, but whether the base model fits on it at streaming speed.

## The C++ engine is written for MacBooks, while offline inference reaches NVIDIA GPUs

Two runtimes with two different reach. The C++ inference library, magentart::core, is described as being for efficient streaming audio generation on Apple Silicon MacBooks, and the example applications, including the AUv3 plugin and the standalone app, sit on top of it. The Python library, magenta-rt, is the wider door: both models can run offline, non-real-time inference on any Apple Silicon Mac or on an NVIDIA GPU through it, with the details in the models documentation. That distinction matters for anyone without a Mac. The model weights are on the Hugging Face Hub and the package installs from PyPI, so a Linux or Windows machine with an NVIDIA card can generate music, just not at playback speed and not through the plugin. The macOS and POSIX Linux operating system classifiers both appear in the metadata, which reflects the Python path rather than the engine.

## Two model downloads come before the first note, and they fetch different things

The quickstart on Apple Silicon installs uv by piping its install script into a shell, creates a virtual environment on Python 3.12, and installs the package with its MLX extra. Then the model steps run in order. `mrt models init` downloads the resources, which the comments identify as the style model and the codec model, MusicCoCa and SpectroStream. `mrt models download` fetches the streaming model you intend to use, and only then does generation run:

```bash
mrt models init
mrt models download
mrt mlx generate --prompt "disco funk" --duration 4.0 --model=mrt2_base
```

The last line is a four second sample from a text prompt, with a model flag choosing between the two sizes. So a first run pulls three distinct sets of weights, and the codec and style models are not optional extras: they are the resources the streaming checkpoint is conditioned on. Offline inference paths use the same resources, which is why the models documentation covers the checkpoints rather than the quickstart.

## sequence-layers is vendored as a submodule, with a note about when to remove it

The packaging metadata carries two comments that explain more about the project than the feature list does. Both are labelled as notes about vendoring, and both say the same thing: once sequence-layers is available on PyPI, it should be added as a dependency and typeguard, jaxtyping and recurrentgemma should be removed, because the three are pulled in by that package. Until then sequence-layers lives as a git submodule under magenta_rt/_vendor/sequence-layers, which is also why the clone instructions carry the recurse-submodules flag. A commented-out uv sources entry points at that vendored path for local editable development. One related detail is worth noting: typeguard is pinned to an exact version, 2.13.3, while most other dependencies float, so that one is held in place deliberately rather than by accident.

## The C++ setup pins cmake below 3.28 and the sample command carries absolute paths

Building the C++ side is where the rough edges show. The dependency step asks for cmake<3.28, an upper bound rather than a minimum, which means a machine with a current system cmake has to install an older one into the environment instead of using what it has. The build itself is a configure and a targeted build of the hello_mrt2 command line interface, with a parallelism flag. The invocation that follows is where a newcomer stumbles: the sample passes absolute paths under a Documents folder for both the model checkpoint and the resources directory, followed by a bare 100 and a prompt argument. Those paths are illustrative rather than wrong, but they mean the example cannot be pasted unchanged, and nothing in the snippet explains what the 100 stands for. Build the target first, then supply your own paths.

## The README highlights four example applications while the examples directory holds more

The repository highlights list names magenta_rt for the Python library, core for the C++ library, and four applications: an all-in-one AUv3 plugin for DAWs under examples/mrt2/auv3, an all-in-one standalone macOS app under examples/mrt2/standalone, a note control app under examples/jam, and a prompt space explorer under examples/collider, plus a notebook for trying the Python API. The examples directory itself holds more than that: a hello_mrt2 command line project, further entries named max, pd and sc, a shared common directory and a scripts directory, along with a package.json and its lockfile, which is what an AUv3 plugin bundle needs. The headline therefore undersells what is there, and the examples README is the place to get the full list rather than the top level summary.

## Two license header files exist, and one of them is for shell scripts

The root of the repository is unusually fussy about legal text, in a way that reveals how the code is built. There is the Apache-2.0 LICENSE, a MODEL.md describing the weights, a CHANGELOG.md, and then two separate header files: LICENSE_HEADER.txt and LICENSE_HEADER_SH.txt, the second one evidently for shell scripts. A pre-commit configuration sits beside them, so headers are enforced by a hook rather than by review, which is why there is a distinct header for a distinct file type. Build configuration follows the same pattern with a CMakeLists.txt at the root and a uv.lock for reproducible Python installs. It is a small detail, and it is the kind of detail that separates a research release from a research prototype: the intent is that a patch arriving from outside carries the same header as one from inside.

## Version 1 is on a branch, fine-tuning is a promise, and one release is tagged

Three loose ends are declared in the same short file. Version 1 is not gone, it is parked: the original model and code have been moved to a v1_legacy branch, while main carries version 2, so anything built against the first release is a port rather than an upgrade. Supervised fine-tuning is described as something future updates will support, which is a promise rather than a feature, and the current state is inference, plugin and embedding work. The release list shows one tag, v2.0.3, published 2026-07-30, with the most recent commit dated 2026-10-02, so there is work after that tag that a pip install will not have. Pre-built apps and plugins are not in this repository at all, they are distributed from a separate site, and the citation the project asks for is the Live Music Models technical report.

## Conclusion

Magenta RealTime 2 fits a Mac owner with an M-series chip who wants a local model that generates audio faster than playback and a plugin they can drop into a DAW. Three practical notes. Real-time streaming is the narrow path: the 2.4B model needs a Pro or Max chip, and the C++ engine is Mac specific, while offline inference through the Python library reaches NVIDIA GPUs. Two model download steps come before the first note, one for the style and codec resources and one for the streaming checkpoint. And version 1 now lives on a separate branch, so anything written against it has to be ported rather than upgraded.

## FAQ

### What is magenta RealTime?

Magenta RealTime 2 is an open-weights model for real-time music generation from Google, published on the Hugging Face Hub. The repository also carries a Python library called magenta-rt for inference with JAX and MLX backends, and a C++ inference engine called magentart::core for streaming audio on Apple Silicon MacBooks.

### Which Macs can run Magenta RealTime 2 in real time?

Real-time streaming requires Apple Silicon. mrt2_small at 230M parameters runs in real time on any Apple Silicon Mac including the Air models, while mrt2_base at 2.4B parameters needs a Pro Max chip; the device table marks the M2 Pro, M1 Pro and the Air chips as small-model only.

### Can Magenta RealTime 2 run on an NVIDIA GPU?

Yes for offline, non-real-time inference through the Python library, which the documentation says works on any Apple Silicon Mac or an NVIDIA GPU. Real-time streaming is the Apple Silicon path, and the C++ engine is written for MacBooks.

### What has to be downloaded before the first generation?

Two steps. mrt models init fetches the resources, which the quickstart comments identify as the style model and codec model, MusicCoCa and SpectroStream. mrt models download then fetches the streaming model itself, after which mrt mlx generate produces audio from a prompt.

### How does Magenta RealTime 2 differ from version 1?

The original model and code were moved to a v1_legacy branch, so version 2 is a separate codebase on main rather than a continuation of it. It ships as an open-weights model, a Python library, a C++ engine and example applications, with supervised fine-tuning described as coming in future updates.

## Sources

- [License: Apache-2.0](https://github.com/magenta/magenta-realtime/blob/main/LICENSE)
- [magenta/magenta-realtime on GitHub](https://github.com/magenta/magenta-realtime)
- [Project website](https://magenta.withgoogle.com/magenta-realtime-2)
- [README](https://github.com/magenta/magenta-realtime/blob/main/README.md)
- [Releases](https://github.com/magenta/magenta-realtime/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/magenta-magenta-realtime