Loom by SubverseLab

List every parameter on a track whose automation can be written -- mixer and device alike -- with its automation target id and declared range. A parameter that does not declare a range is left out rather than written with guessed bounds. Filter before raising the limit: a single EQ Eight carries 85 parameters.

List every automation envelope in an .als, resolving each PointeeId to the owning device and parameter. Read-only -- nothing in this stack can write automation yet.

Write an automation envelope onto a track's mixer parameter in an .als. The envelope targets the parameter's own AutomationTarget id -- nothing is invented -- and values are checked against that parameter's real range. Dry run by default; applying writes a timestamped backup, saves atomically, then reloads the file and compares every point.

Copy a device chain from one track to another inside the same .als. Device XML is never synthesised -- it is cloned from a real device with fresh Pointee ids. Refuses to overwrite a track that already has a chain. Dry run by default; applying writes a timestamped backup first and re-reads the file to verify.

What device chains the user actually builds, counted from their own projects. With no role, returns the whole measured summary; with a role, the evidence-backed chain and each device's presence rate. A role with too little data returns no recommendation instead of a guess.

For every track in an .als, report its role, its current device chain, the evidence-backed chain for that role, and which track in the same project could donate it. Read-only.

THE crate trigger: from one source (YouTube URL or file) to a measured sample pack in one call. Fetches, reads the audio (tempo, key, quality), finds the chop spots, picks the chop mode from the evidence -- bars on the reader's own grid when the tempo is measured and inside the chop range, transients otherwise -- slices, and writes a pack whose manifest carries the reading, the spots and the reason for every choice. Nothing is guessed: a tempo the reader could not measure is reported as such and the pack falls back to transients. Dry run by default reports the plan without writing.

Slice a recording into a sample pack the way the Sampler CLI does: modes transient, bars, fixed, silence, leftover or all; WAV slices per mode with fades, optional normalisation, a manifest that records how the slices were really produced (a given --bpm writes that grid, not librosa's estimate). Returns the pack directory, per-mode slice counts and the analysis.

Bring a source into the crate: a YouTube URL (yt-dlp + ffmpeg) or a local audio/video file, optionally trimmed, decoded to a 44.1 kHz stereo WAV in the crate's work directory. Returns the WAV path and the source metadata (title, video id, duration, trim). The SubverseLab Sampler's fetch stage.

Measure the audio itself, not its file name: level, noise floor, silence share, stereo width, tempo (from loop length + autocorrelation octave choice, 82% measured accuracy vs 31% for beat tracking) with its chop-range fold, onset rate, key with confidence, brightness and harmonic ratio. Says why when it cannot answer (one_shot, no_plausible_bar_count, ambiguous key, ableton_compressed). The SubverseLab sample-reader.

Find chop candidates inside a longer recording: the top N windows ranked by harmonic content, onset density and level, each with a bar count, a score and the reason, plus the beat grid the ranking used. With a YouTube video id, the watch URLs that loop each spot. The sample-reader's spots stage.

Put a crate slice (or any audio file) into the running Live set as an audio clip: Live imports the file into the project folder (its own managed copy) and creates the clip in a session slot or at an arrangement position on the named audio track. The answer carries the imported path Live chose and the clip it made.

Build the native EQ Eight -> Glue -> Utility drum buss chain in an .als. Dry run by default; applying writes a timestamped backup first and verifies the result after saving.

Read the drum buss device parameters out of an .als and report whether they match the conservative preset. Read-only.

Log an identified missing control, untested path, or desired Live API feature into docs/MISSING_CONTROLS_LOG.md.

Musical evidence measured from open corpora of real performances, served one layer at a time. 'drum' returns where each drum part falls on the bar for a style, counted from 1,150 human drummer takes. 'bass' returns how the bass sits against the chord and how far it moves. 'chord' returns degree transitions and melodic intervals. 'arrangement' returns song-level shape -- chord counts, loop lengths, modes -- which is what ArrangementGPS needs to build a project rather than write notes. Layers are kept apart on purpose: a bass line judged by a kick pattern answers the drum question, not the bass one. A style that was never measured returns nothing instead of an approximation.

Search Sensei's preset identity catalog (role- and genre-tagged, so a hit is something Sensei can actually generate for) with an optional filesystem fallback for name-only lookups.

The single connection diagnosis: which Loom extension bridge the MCP talks to (and why), its freshness, session and published capabilities, the operations the SDK cannot do, and what is waiting in the queue. Says whether this MCP may send mutations to the running extension (protocol verdict: OK / UPGRADE_REQUIRED / PROTOCOL_MISMATCH / STALE_STATE / NO_STATE) and the state of its replay journal. There is no fallback endpoint.

Make a live change inside a running Ableton Live through the Loom extension: set tempo, mixer volume/pan/mute/solo, a device parameter, a locator, a new MIDI track (with a native instrument device when the SDK can insert it), an audio file imported into the project as a clip, a pre-effects render of an audio track range, or read a Drum Rack's pad notes (drum_pads); delete_track / delete_locator remove what an earlier build left behind (a track only when it holds no clip and its devices are named exactly). The extension writes the real before/after values back, so the answer is what Live actually did. Operations the Extensions SDK has no API for -- transport, set_key, preset loading, the capture_* recording steps -- are answered UNSUPPORTED_BY_SDK before anything is sent.

Open, inspect or close an Ableton Live project. Live's own scripting cannot open or close a set, so this drives it from outside and then reads Live's own log to say whether the set really loaded -- whether it was corrupt, how many clips Live had to repair, and which audio files it could not open. Opening another set while Live is running can raise Live's unsaved-changes dialog, which only the person at the keyboard can answer; nothing is discarded automatically.

Read Ableton Live's current state -- which set is open (name, path, saved or not; from Live's log and window title, the SDK has no such field), tempo, transport position, selected track, every track's mixer values and devices, and the song's locators. Published by the Loom extension running inside Live (the SDK exposes no transport or time signature; those are null). Always reports how old the snapshot is and whether it is fresh; if Live is not running it says so instead of returning stale data as if it were live.

Generate evidenced MIDI variations using Sensei's locked dataset and variation runtime for a verified target role/preset.

Write MIDI notes into the ARRANGEMENT of a running Live session -- a named track, a bar position, a length -- through the Loom extension. Every note, length and target is validated in Live before anything changes. A clip in the range that Loom did not write is never touched (the write is refused); Loom's own clip there is replaced only with on_conflict=replace_owned, so rebuilding a section is safe and a user's clip is safe. Reports the note count Live holds and whether the notes match note-for-note; NOT_CONSUMED means the request was withdrawn unapplied, INDETERMINATE that Live picked it up and never answered.

Write MIDI notes into a session clip in Ableton Live through the Loom extension bridge (op write_clip on the common protocol) and wait for Live to answer. Reports WRITTEN_TO_LIVE, REJECTED_BY_LIVE, NOT_CONSUMED (withdrawn, nothing applied) or INDETERMINATE (Live picked it up, no answer). An occupied slot is never overwritten unless the clip is Loom's own and on_conflict=replace_owned.

Full Mix Check of one audio file: the measurements of mix_measure plus one-third-octave spectrum, tonal map with key candidate, noise floor, section summaries, mono fold-down compatibility, and evidence-backed findings. Optionally compared against a reference file or one of the stored Genre Profiles (measured from released masters: electronic, hiphop, jazz, metal, pop, rock); use_closest_profile ranks the track by technical proximity, which is not a genre classification and is labelled as such. Findings only appear when a measurement is actually outside the comparison range; limitations are listed with every result.

Measure the mix from Live's own playback, no render, with a Core Audio process tap on the Live process (method 'tap': macOS 14.2+, needs the System Audio Recording permission for the app running Loom; captures silence until granted -- experimental, the permission target is unverified). Then Mix Check measures or analyses the capture. method 'resample' (Live recording itself) and follow_transport need record mode and transport state, which the Extensions SDK does not expose: both answer UNSUPPORTED_BY_SDK.

Measure what a track in the running Live set actually sounds like before its effects: the extension bridge renders the audio track's arrangement range pre-fx into its temp directory, then Mix Check measures the file (mix_measure) or analyses it (mix_analyze). One call from Live to numbers.

Direct signal measurement of one audio file (a stem, a bounce, a master): duration, sample rate, channels, sample peak dBFS, RMS dBFS, crest factor, ITU-R BS.1770 integrated loudness through pyloudnorm, and per-channel peak/RMS/DC offset. Silence and too-short files come back with null levels and a status, never a made-up floor. No true-peak guesses, no custom loudness range. The SubverseLab Mix Check engine, running locally.

List the stored Genre Profiles mix_analyze can compare against: id, name, how many released masters each was measured from, and the measurement contract version.

The user's measured sound palette -- which sample sources and instrument devices actually recur, per role, ranked by how many separate projects each appears in. Bounces, freezes and reverb impulse responses are excluded.

Write a chord progression or bass line FOR A SPECIFIC PROJECT. Reads the project's own key, scale and tempo first, walks a chord sequence through transitions measured from 909 annotated songs, and returns notes already in that project's key and beats -- so the part belongs to the session rather than having to be bent to fit it. This is the thing a prompt-driven generator cannot do: it does not know your key or your tempo. Returns what it read from the project and what it counted, so every choice is traceable. A layer with no measured evidence is refused, not guessed.

Build a project from scratch: run the real pipeline from a text prompt (blueprint -> build plan -> session plan -> package -> action list) and write a build directory ArrangementGPSBuilder picks up in Live. Tempo, key, mode, genre and instrument choice are derived from the prompt. Each section carries a 0-100 energy and the plan carries a genre; when the Live-side writer fills the sections it hands Sensei that energy as density (an intro is written from a pattern that is already sparse, a final hook from one already busy) and the genre as genre_style (candidates ranked against drum patterns measured from real performances). Every part is written in the project's own key and tempo.

Check the current session plan against Sensei's catalog -- every track with a Sensei role must name an instrument that resolves to exactly that role. Catches the Live-side instrument_role_unresolved failure without opening Live.

Check arrangement clips for gain/fade/automation alignment problems -- clip gain outside the allowed range, missing fades, and clip vs track volume automation conflicts.

Full gain-staging and mixer analysis of an .als -- real fader values, Utility gains, routing kind, send routes, and master-chain limiter/clipper/compressor detection, with a markdown report. XML only; peak/RMS/LUFS targets need rendered audio.

THE single trigger: build a whole project into the running Live session from one prompt, through the Loom extension. Runs plan_create (its own run directory), validates the plan, checks the extension's published capabilities, then in order: tempo -> tracks (created or adopted, a native instrument inserted when the SDK can, Drum Rack pads read back as evidence) -> a part per section and writable track (drum, bass, chord; the section's energy as density, the plan's genre as genre_style, in the project's key and tempo) -> a locator per section -> a read-back of the state. Song key is reported UNSUPPORTED_BY_SDK, never faked. A track whose instrument or pads could not be verified gets blocked writes, not silent ones; when the bridge stops answering the remaining writes are aborted. The answer's status is completed / partial / blocked / failed / indeterminate. Dry run by default: it reports exactly what it would write and touches Live only with dry_run=false.

Analyze track names, arrangement density, and instrument presence in an .als file to predict multi-label genre tags.

Build the plan's tracks WITH THEIR REAL PRESETS as a Live set file. The Extensions SDK cannot load a preset into an open set (insertDevice: built-in device, default preset only), so the set is written on disk from Live's own template: one MIDI track per plan track, the preset ArrangementGPS chose (a Drum Rack .adg with its DrumCells, macros and choke groups; an Instrument Rack; an .adv) converted into set XML by Presetor and refused whenever a produced node does not match, tag for tag and attribute for attribute, what Live itself writes; the plan's tempo. No representative device is ever inserted: a track whose preset is not on this machine is not created and is listed under unresolved. Writes a manifest next to the set; open the set in Live, then project_build(plan_path=..., set_manifest=...) writes MIDI and locators into those tracks with the kit verified against the manifest. Measured 2026-09-07 on Live 12.4.15b1: the first such set loaded with 0 repairs.

Inspect an Ableton Live Set (.als) file in detail: tempo, key, scale, Camelot code, track breakdown, mute states, and active devices.

Read an .als arrangement -- tempo, time signature, locators, and the section boundaries inferred from where clips start and stop across tracks.

List one project's sound sources -- instrument devices per track and the samples they load.

Scan a library of .als projects and report how the user actually arranges -- section lengths, section counts, song lengths and tempos, inferred from clip boundaries. Evidence for arrangement templates instead of guesswork.

Build a per-track stem export manifest from a real .als, deciding from the project itself which tracks can be rendered and why the others cannot (MIDI needs a freeze, groups and returns are excluded).

Measure exported stems against the project's own render manifest -- which expected file is missing, which is silent, which has the wrong channel count. Rendering itself needs Live's audio engine and cannot be done from here; this checks the result afterwards.

First-run setup: build Loom's catalogues from the stock Ableton library on THIS machine, read out of Live's own file index. Loom ships code and fixtures but never measurements, so each user generates their own. Reports state by default and writes nothing until asked.