Controlling Ableton Live Over OSC with AbletonOSC

This module is where your rig stops being “a laptop running Live” and becomes a programmable instrument: an external process — a Python script, a visual host, a generative system — driving an entire Live session over UDP. In an AV performance context this is the backbone move: your code fires clips, nudges tempo, writes MIDI notes into a running clip, and sweeps a synth’s filter, all without touching the Live GUI.

The arc starts supported. First, internalise the Live Object Model tree — Song at the root, tracks, clip slots, devices, parameters, all zero-based — because every OSC address you will ever send is a path plus indices into that tree. Install AbletonOSC as a MIDI remote script (no Max for Live needed) and send your first transport commands: start/stop and tempo via the Song API. Then wire the reply side using the fixed 11000/11001 port pair, and wrap it in the synchronous client pattern (threading.Event blocking on the reply) so queries feel like function calls. From there, layer in note editing, device parameter control by index, clip-slot firing for session-style launching, wildcard queries for one-shot property sweeps, and the single-message bulk track_data query to sync your panel to the set’s state.

Each required atom gates a clause of the capstone: you cannot build the panel without addresses (LOM), transport, notes, parameters, firing, replies, sync queries, wildcards, and bulk reads. The supporting atoms enrich rather than gate — the M4L view of the LOM, the internal dispatch and track_data implementations, launch quantization codes, and runtime CC mapping are where to go when you want depth or your queries behave unexpectedly.