engine
Skill16 starsChanged 36 days agoMITView on GitHub
Shared engine for the ableton-tools skills — a uv-managed Python library behind the single 'ableton' dispatcher (stem verification, levels/locate, tempo/drift/warp analysis, MIDI transcription/comparison, safe lossless .als editing, stem import, session building, device transplant). Invoke a specific ableton-tools skill for a task; use this directly to run a raw subcommand, extend the library, or when the 'ableton' command cannot be found.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- illodev/drawn-by-codetheir own version, first seen Nov 4, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- illodev/drawn-by-code★ 45same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository8 other files it gives its agents.
- engine/CLAUDE.mdCLAUDE.md
- als-buildSkill
- als-filesSkill
- als-warpSkill
- midi-compareSkill
- midi-transcribeSkill
- stem-verifySkill
- tempo-driftSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 20
If ableton is not on PATH (plugin disabled, headless quirk), call the dispatcher directly: <plugin-root>/engine/bin/ableton, where …
- Very specific: line 66
Every mutating als subcommand defaults to a dry-run JSON diff (with a validation report).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
This skill is the engine behind the ableton-tools command skills. It bundles
reusable signal-processing and .als-editing logic distilled from a set of
one-off analysis scripts (see engine/references/source-scripts.md).
Running the dispatcher
The plugin puts ableton on the Bash PATH:
ableton <subcommand> [args] [--json]
ableton manifest --json lists every subcommand with its arguments,
including nested ones. The shim runs under uv and adds the heavy
transcribe extra only for ableton midi transcribe.
If ableton is not on PATH (plugin disabled, headless quirk), call the
dispatcher directly: <plugin-root>/engine/bin/ableton, where
<plugin-root> is this skill's grandparent directory — the plugin cache
copy (~/.claude/plugins/cache/ableton-tools/ableton-tools/<version>) or a
local checkout of the repo.
Subcommands
stem-verify --stems <dir> --master <file>— does a stems folder sum to a master?levels <dir> [--ref FILE]— dBFS, silence, duration/rate, r vs a reference.locate --fragment F --ref R— where a fragment occurs in a reference.warp-check <file.als>— warp markers vs real beats; clips sharing the map.tempo <file> [--hint-bpm N]— detected BPM, sub-ms precise BPM, and drift.drift --master <file> --stems <dir>— per-window time-drift trace.midi transcribe <audio> [--out file.mid]— audio → MIDI (basic-pitch).midi compare <a.mid> <b.mid> [c.mid]— chroma similarity + timing drift.als inspect <file.als>— tempo, tracks (group/routing/mute), clips (session/arrangement, Time, warp-map BPM), file refs as JSON.als validate <file.als>— structural checks + typed ref report (read-only).als rename|move <file.als> --manifest map.json— patch file references.als warp-to-grid <file.als> --tempo BPM --clips clips.json— grid-lock clips.als move-clip <file.als> --clip NAME --to-beat B [--dur-s S --bpm BPM].als snap <file.als> --manifest snaps.json— batch clip repositioning.als import-stems <file.als> --master-track <id|name> --stems <dir>— clone a warped master per stem and relink (see the als-files skill).als set-tempo | mute | add-track | group | sync-to-master— session building (see the als-build skill).als transplant-devices <target.als> --from <src.als> …— copy a device chain between sets (experimental; see the als-build skill).
Verdicts are yours, not the tool's
By design, commands emit raw numbers plus threshold bands (e.g. stem-verify
returns worst_db, median_db, and bands). Read the JSON and state the
verdict yourself — no LLM/API call is built in.
Errors are structured
Operator-correctable failures exit nonzero with {"error": ..., "hint": ...}
on stderr (JSON mode) or error:/hint: lines (human mode), plus a kind
where one applies. kind: "internal" (exit code 4) is an engine invariant
that failed: nothing was written, and it is a bug to report. Any other
traceback is also an engine bug, not a usage problem.
Safety for .als edits
Every mutating als subcommand defaults to a dry-run JSON diff (with a
validation report). Pass --commit to write. The commit refuses while
Ableton Live is running (--force overrides; Live would overwrite the edit
on its next save) and when the file changed since it was read; it validates
the result first, backs up to <project>/Backup/<basename> [YYYY-MM-DD
HHMMSS].als (Ableton's native convention — visible in Live's rollback UI),
writes, then re-verifies project-relative file refs and restores from the
backup if any break. Edits are lossless byte splices (alsxml). Always close
Ableton before committing edits to a .als.
Library API (for extension)
engine/src/ableton_tools/: audio (I/O, mono-sum, envelope), align
(xcorr + LSQ lag), cancel (cancellation dB, stem_verify), tempo, midi,
transcribe, alsxml (lossless span-indexed .als access + byte-splice
edits), als (inspect + patchers + clone_track), validate (structural
checks + typed refs), commit (guarded commit pipeline), import_stems
(stem-import policy + color convention), session (tempo/mute/add-track/
group/sync), devices (chain transplant), analysis (levels/locate/
warp-check), errors (UsageError, InternalError). See
engine/CLAUDE.md for JSON shapes and engine/references/ for the .als
format notes and source-script lineage. Dev loop, from the repo root:
uv run --project engine --group dev pytest, uvx ruff check engine,
uvx pyright --project engine engine/src (the --project is required; see
engine/CLAUDE.md).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

