For a few years now I’ve been building Protocol 0 , a global keyboard shortcut manager for Ableton Live 12. The starting point is simple: Ableton’s native key mapper is limited to a single set, doesn’t handle key combinations, and cannot be extended with custom actions. Protocol 0 fixes that.

This article describes the current technical architecture. For product context and installation, the official site is the best place to start. For a historical deep dive into the remote script’s object model, see my older article .

The problem: controlling Live from outside

There are several ways to extend Ableton: Max for Live, remote scripts, and — since very recently — Extensions . All of them allow the user to interact with the Live Object Model and mostly script anything that could be done on the interface with a mouse.

Unfortunately, as it stands, there is no way of registering keyboard shortcuts for any of these methods. So I’ve come up with an alternative idea: what if the remote script (or extension) exposed its own API via an HTTP server? It turns out this approach works both in the remote script and the extension (probably in M4L too, I didn’t test) and works perfectly. You just need a bit of plumbing code, and then you can call your actions from anything that can call a URL. For example:

• An AutoHotkey script on Windows
• An Elgato Stream Deck
• Any program that can send an HTTP request
• And of course my own Protocol 0

This finally makes it possible to control Live in a way that wasn’t possible before.

The architecture

Protocol 0 is built on a Python remote script — it’s the best way (at least for what I wanted to do) to interact with Live. It’s easier to work on than Max for Live and has fewer limitations than the Extensions SDK (which is really cool though).

But I want to trigger actions from any key on the keyboard, even when Ableton doesn’t have focus. A remote script alone isn’t enough: you need a native OS-level process that listens to the keyboard globally, then relays the intent to the script, which in turn drives Live.

Hence an architecture made of several pieces that talk to each other.

1. The remote script (inside Ableton)

This is a full Python project running in Live’s embedded interpreter. It exposes the Live API (track creation, note editing, parameter changes…).

2. The local HTTP backend

The script embeds a small HTTP backend (FastAPI) listening on localhost. Each action exposed by the script becomes a route. Concretely, adding an action boils down to decorating a method: it becomes automatically callable via POST /api/action/<plugin>/<method>. The backend also serves the configuration UI available on localhost:9010.

3. The native keyboard hook

The component that listens to the keyboard globally is an OS-level process — catching a shortcut while Ableton doesn’t have focus requires a native hook — you can’t get there with Ableton’s embedded Python interpreter, which runs in a limited environment. I solved this by writing a Rust agent that runs in the background.

👉 More details and the installer at protocol0.live .