Measurement-based production for Ableton Live.
Loom is a local MCP server that reads your own .als projects and your own
Ableton library, answers with counts instead of guesses, and writes MIDI, device chains,
automation and arrangement markers into a running Live session — verifying every write
by reading it back. It is open source and free: no account, no upload, no server.
Seven engines under one tool namespace — Sensei, ArrangementGPS, AIMixMaster,
Presetor, AISoundDesigner, MusicalIntelligence and the Loom extension — exposed as 45
MCP tools. python3 install.py registers it with Claude Desktop, Claude Code and
Antigravity; Live’s own step is to add the extension package under Extensions in Live
12.4 beta and restart.
The single connection to Live is the Loom extension. There is no Control Surface, no automatic fallback and no second writer, and an extension too old to publish a protocol is read but never written to.
Ableton’s extension SDK opens some doors and not others, and most of what Loom does
lies past the ones it leaves shut. The SDK cannot load a .adg or
.adv, so Loom reads the preset’s own XML, resolves the sample files on the
machine and rebuilds the pads in Live as chain, Simpler and sample — then names what did
not carry across. Device chains are harvested from .als and .adv
files and load with no repairs. Live stores a drum pad’s ReceivingNote
inverted, as 128 minus the note; nothing documents that, it was measured on real pads and
confirmed 16 of 16. Live’s audio output has no SDK route, so Loom takes a Core Audio
process tap. Gain staging, clip alignment and automation writing happen on the
.als file itself, outside the SDK entirely.
Source: github.com/senolsahan037-oss/loom. © Şenol Şahan / SubverseLab.