Releases: cssllcio/vibrai-releases
Release list
Vibrai v1.7.3
Claude Desktop extension (Vibrai-1.7.3.mcpb) — published here because the MCP registry only accepts packages hosted on GitHub/GitLab.
All other downloads (installer, CLI tarballs, checksums, signed manifest): https://vibrai.com/download
Vibrai v1.7.2
Claude Desktop extension (Vibrai-1.7.2.mcpb) — published here because the MCP registry only accepts packages hosted on GitHub/GitLab.
All other downloads (installer, CLI tarballs, checksums, signed manifest): https://vibrai.com/download
Vibrai v1.7.1
Claude Desktop extension (Vibrai-1.7.1.mcpb) — published here because the MCP registry only accepts packages hosted on GitHub/GitLab.
All other downloads (installer, CLI tarballs, checksums, signed manifest): https://vibrai.com/download
Vibrai v1.7.0
Claude Desktop extension (Vibrai-1.7.0.mcpb) — published here because the MCP registry only accepts packages hosted on GitHub/GitLab.
All other downloads (installer, CLI tarballs, checksums, signed manifest): https://vibrai.com/download
Vibrai v1.6.6
Claude Desktop extension (Vibrai-1.6.6.mcpb) — published here because the MCP registry only accepts packages hosted on GitHub/GitLab.
All other downloads (installer, CLI tarballs, checksums, signed manifest): https://vibrai.com/download
Vibrai v1.6.5
Claude Desktop extension (Vibrai-1.6.5.mcpb) — published here because the MCP registry only accepts packages hosted on GitHub/GitLab.
All other downloads (installer, CLI tarballs, checksums, signed manifest): https://vibrai.com/download
Vibrai v1.6.4
Claude Desktop extension (Vibrai-1.6.4.mcpb) — published here because the MCP registry only accepts packages hosted on GitHub/GitLab.
All other downloads (installer, CLI tarballs, checksums, signed manifest): https://vibrai.com/download
Vibrai v1.6.3
A fix release, and the fixes are audible. Five drum part types have been quietly generating the same rhythm as each other since they shipped; break and fill placement has been counting in 4/4 on sets that aren't. Both are corrected here — which means some presets now generate different notes than they did in 1.6.2.
Your crash, fill and percussion stop copying the kick
HiHatPlus, Percussion, Crash, Fill and Roll had no Euclidean cell of their own, so all five fell back to the same generic 4-pulse pattern. A crash hit, a drum fill and a shaker part produced the literal identical rhythm, differing only by seed and pad.
Each now has its own cell, authored per part and checked by ear: sparse loud accents for Crash, dense pre-transition activity for Fill, off-grid movement for Percussion.
This changes generated output. Any preset using those five part types will produce different notes than it did in 1.6.2. Every other part type is untouched.
Bars that land where your meter says
BreakOverlay computed step offsets from a hardcoded 4/4 sixteenth, even though it already carried the real meter and derived bar boundaries from it. At any non-4/4 meter, step N landed on the wrong beat. Break and fill steps now use the same grid the rest of generation does — which also realigns them with the shadow kick grid they are supposed to lock to.
The installer stops refusing while Live is open
It used to exit with an error if Ableton was running, which is a support ticket for something you can solve yourself. Now it warns, proceeds, and tells you to restart Live.
That matters because Live reads the Vibrai device and the remote script at startup. Install over an open Live and the new files sit on disk unused. The installer can't tell you that — nothing inside a macOS package reaches your terminal — so vibrai version does:
vibrai versionIt now names any bridge serving a different build than the CLI and tells you to restart Live. Believe it over the installer's "successful".
Three JSON fields that were reporting the wrong number
If you script against Vibrai's --json output, read these — each is a breaking change to a value you may have compensated for:
scene_indexwas reported raw and 0-based bynotes set/notes addand their MCP siblings, whiletrack_idbeside it was already converted to the 1-based wire format. The write itself was always correct; only the reported number was off by one. If you were subtracting 1, stop.automation renderemitted a raw Live track id, a convention belonging to the olderautomation apply. It now matchesrender_automation, which never had the ambiguity.generatereturnedwarnings: nullwhen there was nothing to report, whileplanreturned[]for the same key. It is always an array now. Code branching onwarnings === nullwill take the other branch.
Also in this release
- 12 shipped genre files carried
automation:blocks that pointed at nothing and were silently skipped every render. Removed. vibrai updatecan no longer leave you with new CLI binaries and an untouched Ableton device — the Ableton-side reinstall now runs before the binary swap, not after.- The MCP user guide documents the eight generate-time style knobs (
swing,humanize,ornament_density,dropout,gate,native_randomization,bass_motion,kick_relation). They were only in the older combined guide before.
Full list of merged pull requests
What's Changed
- ci(migration): stub migrate-secrets.yml on main so workflow_dispatch can resolve it by @gitizenme in cssllcio/Vibrai#790
- docs(plan): migration copies secrets pre-transfer instead of regenerating them by @gitizenme in cssllcio/Vibrai#791
- docs(triage): route non-release work to programme milestones, not version numbers by @gitizenme in cssllcio/Vibrai#793
- docs(plan): the copy tool is now one commit + a tag; runbook knows both refs by @gitizenme in cssllcio/Vibrai#794
- docs(plan): migration timing — the v1.7.0 → v1.8.0 gap, event-triggered by @gitizenme in cssllcio/Vibrai#797
- Demo shorts Phase 1: docs-driven episode toolchain (spec, stage/shoot/check-release, S01–S03) by @gitizenme in cssllcio/Vibrai#799
- v1.6.3 release plan: spec + implementation plan (28 issues → 24 tasks) by @gitizenme in cssllcio/Vibrai#792
- feat(mix): resolve compression targets through Live's own display units (#777) by @gitizenme in cssllcio/Vibrai#801
- shorts: recorder = ScreenFlow (D7), per-display stage layout (D2′), HID hotkeys, driver focus, Voicebox VO bed by @gitizenme in cssllcio/Vibrai#804
- v1.6.3: 23 tasks closing 26 issues by @gitizenme in cssllcio/Vibrai#811
- docs: version stamping + vibrai doctor — design and implementation plan (#795, #796) by @gitizenme in cssllcio/Vibrai#812
- release-plan: every plan ends with a release-candidate task by @gitizenme in cssllcio/Vibrai#814
- Installer no longer fails on a running Live; report stale bridges instead by @gitizenme in cssllcio/Vibrai#817
- docs: add brand handoff bundle (briefs, reference material, apply script) by @gitizenme in cssllcio/Vibrai#822
- v1.6.3 triage: clear four milestone issues (#806, #385, #415, #467) by @gitizenme in cssllcio/Vibrai#824
- Scoping gate: window the closed-issue query server-side (#826) by @gitizenme in cssllcio/Vibrai#831
- docs(plan): record the approved exception for #467's unverified integration fix by @gitizenme in cssllcio/Vibrai#836
- Claude/release v1 6 3 3350ca0a by @gitizenme in cssllcio/Vibrai#841
Full Changelog: cssllcio/Vibrai@v1.6.2...v1.6.3
Vibrai v1.6.2
Vibrai could already set a level, a pan and a send. This release is about telling you what to set them to — a starting mix per part, the reasoning attached, and a reference you can ask when a mix is muddy and you don't know whether that wants EQ, compression or automation. Alongside it: generate stops silently doubling your tracks, and bar.beat positions finally land on your bar lines.
A starting mix, with the reasoning attached
A mix profile answers, per part type, two questions: where does this sit and what belongs on its chain.
vibrai mix profiles # what's available
vibrai mix suggest --chains # placement + chain advice for the open set
vibrai mix apply-profile --dry-run # what would be written, and why
vibrai mix apply-profile --reverb-return A-ReverbOn MCP those are list_mix_profiles, suggest_mix and apply_mix_profile.
Placement is a starting level, a pan position, and a depth tier on the front↔back axis, expressed as a reverb send. Chain advice is the corrective EQ moves and compressor settings that belong on that part — each with its reason, so you can disagree with it. Profile-wide rules cover headroom, the 2–5 kHz harsh band and return tracks, next to technique notes on serial vs parallel compression, compressor setup, harshness checking and drum impact.
apply-profile writes the placement half only. The EQ and compressor numbers stay advice on purpose: a Live parameter's real range is only knowable from an open set, so a profile cannot honestly pre-compute what to send. mix suggest --chains prints them, and vibrai device set-param (MCP set_device_param) applies them, reporting back the display_value that actually landed.
A part whose depth calls for a send, on a set where you named no --reverb-return (reverb_return), still gets its level and pan — and then warns. Vibrai will not invent a return track for you.
Drop a file at ~/.vibrai/mix-profiles/<name>.yaml to add a profile or shadow a built-in one.
What to reach for, and a compressor set up for you
Hearing that a mix is muddy is easy. Knowing whether that wants EQ, compression, a dynamic EQ or automation is the hard part.
vibrai mix advice # the index
vibrai mix advice compression --for kick # a source
vibrai mix advice compression --for bd # a part type that maps to one
vibrai mix advice reverb --for pre_delay # an entry idmix advice (MCP get_mix_advice) answers from four topics — compression (starting points per source, and the fast/slow attack continuum), reverb (what each parameter does to the tail), low_end (the five ways kick and bass fight, and the fix for each) and tool_choice.
vibrai mix compress 3 Compressor --for bass --dry-run # track 3, the device named Compressormix compress (MCP apply_compression_preset) writes a source's Attack, Release and Ratio onto a compressor already on the track. Threshold is never written — it depends on the incoming level, which no table can know. Any parameter whose units don't match the table, or that the device doesn't expose, is skipped with a warning rather than clamped; the call fails only if nothing is writable.
One honest limit, and it matters most here: mix compress does not yet reach Live's own Compressor or Glue Compressor. The starting points are in milliseconds and plain ratios; measured against Live 12.4.3, both devices report those parameters as normalized 0–1 instead, and Vibrai refuses a value it cannot send honestly rather than guessing. So on the two most obvious targets the command currently writes nothing and tells you why. It works on a compressor that reports real units, and closing the gap needs a value↔display mapping per device — tracked as #777. That refusal is the feature working, not failing: parked at a Release of 1.0 and asked for the bass preset, a Glue Compressor still reads 1.0 afterwards. Nothing pinned, nothing clamped.
~/.vibrai/mix-advice/<topic>.yaml shadows a topic.
generate asks before doubling your tracks
This one changes what an existing command does. On a set that already has MIDI tracks, vibrai generate used to silently append a second set alongside them. It now stops and asks:
vibrai generate --on-existing-tracks replace # delete them and render fresh
vibrai generate --on-existing-tracks append # add alongsideThe MCP generate tool has always refused this way, and both wizards already did on both surfaces — the CLI was the one place a duplicate track set could appear without you asking for it. A script that relied on the old silent append needs the flag added.
bar.beat lands on your bar lines
automation write, get and clear, arrangement place and delete, and seek — on both surfaces — took a bar to be 4 beats regardless of the meter. On a 7/8 project, bar 2 started at beat 4.0 while generation, arrangement and rendering all put it at 3.5. All six now resolve the meter the same way generation does: your project's declared time signature first, then Live's transport, then 4/4. They also take an optional --project / project_path so the declared meter can win, matching every other project-aware command.
The song wizards had the same disagreement with themselves. start_genre_song, start_first_song and vibrai start … resolved the meter after laying out the composition, so on a non-4/4 set the plan and the render disagreed about where bars fell. They plan at your meter now.
device_id says what it takes
Seven MCP tools described the argument as "Device ID or 1-based position number", but any number is read as a 1-based position — so the device_id that list_devices reports (which is 0-based) addressed the device before the one you meant, silently. The descriptions now say 1-based position and warn about that field explicitly, and passing 0 gets an error naming the trap. Behaviour is unchanged, deliberately: every command, every doc example and the whole CLI are 1-based.
Also fixed
- An unseeded
Wandercurve sounds the same on every run. It fell back to a fresh random seed each call, so identical inputs produced a different envelope every time — and forapply_automation_templatethe empty seed persisted into the.vibrai, leaving a file that looked identical while the output moved. "Auto if omitted" now means "auto but stable": varying per target, repeating for the same one. - Reading notes back from an arrangement clip retries like its session-view twin. A single transient bridge failure could report a clip as empty.
brew install vibraiwarns when an older standalone install shadows it onPATH. The install would appear to succeed whilevibraikept resolving to the previous binary.
Under the hood
The bulk of this release is making the test suite mean what it says: nine fail-open and vacuous-pass sites closed, each one a place a green run had been proving nothing. A bare test run can no longer reach the 44 live classes that mutate an open set; genre extraction has a live witness for the first time; and the release gate now blocks on a red m4l or python suite, not just .NET.
All merged pull requests
What's Changed
- docs(launch): T-2 status refresh — v1.6.1 shipped, tool count 115, board drift corrected by @gitizenme in cssllcio/Vibrai#720
- docs(g1): rewrite the shot list against a real v1.6.1 session, typed by typeclip by @gitizenme in cssllcio/Vibrai#721
- docs(plan): v1.6.2 release spec + implementation plan by @gitizenme in cssllcio/Vibrai#722
- docs(g1): shoot driver, playback from section 3, full-film table, and the narration split by @gitizenme in cssllcio/Vibrai#723
- docs(g1): note edits must be re-placed in the arrangement by @gitizenme in cssllcio/Vibrai#724
- docs(g1): shot 10 asked for an outcome, so Claude chose automation by @gitizenme in cssllcio/Vibrai#725
- docs(g1): harden shot 9a, and the ScreenFlow production workflow by @gitizenme in cssllcio/Vibrai#726
- docs(g1): shot lengths in the Window column, and the total they actually sum to by @gitizenme in cssllcio/Vibrai#727
- docs(g1): sync the shoot-day prompt changes across all three surfaces by @gitizenme in cssllcio/Vibrai#728
- docs(launch): T-0 → Tue 2026-08-25, and what the shoot taught about non-determinism by @gitizenme in cssllcio/Vibrai#729
- Mix profiles: placement + corrective-chain advice on both surfaces by @gitizenme in cssllcio/Vibrai#736
- docs(plan): v1.6.2 re-scope — the staleness signal was lying, so it becomes Task 18 (#744) by @gitizenme in cssllcio/Vibrai#745
- feat(mix): encode mixing knowledge as an engine library with both surfaces by @gitizenme in cssllcio/Vibrai#746
- docs(changelog): record the mix-advice feature in [Unreleased] by @gitizenme in cssllcio/Vibrai#754
- fix(harness): close four fail-open paths in the test runners (#687) by @gitizenme in cssllcio/Vibrai#753
- docs(triage): milestone plan for the 15 unmilestoned issues, plus the v1.6.2 version waiver by @gitizenme in cssllcio/Vibrai#757
- docs(plan): v1.6.2 — Tasks 19 and 20, and the patch ruling is falsified (#747, #756) by @gitizenme in cssllcio/Vibrai#758
- fix(tests): gate the integration suite on a live bridge; fail restarts hard (#681, #686, #684) by @gitizenme in cssllcio/Vibrai#759
- fix(tests): replace vacuous passes wit...
Vibrai v1.6.1
Three things in this release change how a session actually goes: you can name the key you want and have Vibrai build in it, the Claude Desktop bundle lands somewhere Finder will show you, and automation stopped running before your instruments existed.
Ask for a key and get it
A genre preset decided the key for you. Now you say what you want:
vibrai genre apply techno hypnotic_1 --scale-root D --scale-name DorianThe same --scale-root / --scale-name pair works on vibrai start genre-song, vibrai plan and vibrai generate, and on their MCP equivalents — apply_genre, start_genre_song, plan, generate.
The important part is when it happens. Vibrai re-keys the composition as it renders, in a single pass, rather than writing the preset's key and transposing after the fact. What comes out is a song in the key you asked for, not a song in the preset's key that has been moved.
Leave the flags out and nothing changes — the preset's own key wins. Vibrai only looks at your open Live set's key when nobody has chosen one, and any part or section pinned to its own scale is left alone.
Chords follow the mode now as well. Vibrai's two chord banks were locked to Aeolian and Ionian no matter what you asked for, so a Dorian project got Aeolian harmony underneath it. Roots and thirds are now built from your project's own mode. Every shipped genre defaults to Minor, so their output is unchanged — this only shows up when you ask for something else.
The Claude Desktop bundle, somewhere you can find it
If you installed Vibrai from the macOS .pkg, dragging Vibrai.mcpb into Claude Desktop is the only way to connect the two — nothing in Vibrai writes Claude Desktop's config for you. That file lived in /usr/local/lib/vibrai, a folder Finder hides by default. The install ended at a door you couldn't open.
vibrai install claude-extension --revealThe bundle now goes into your Ableton User Library under Vibrai/, and --reveal opens a Finder window with it already selected, ready to drag into Claude Desktop → Settings → Extensions. Vibrai reads your real User Library location out of Live's own preferences instead of assuming the default path.
vibrai install all does this as part of a full install, and install_claude_extension is the MCP equivalent.
Automation is its own step
vibrai generate used to write automation as part of the render — and it did it before loading any instruments. Anything aimed at a track it had just created had nothing to aim at yet, so it failed every time, and an explicit automation slot would stop the render outright.
Automation now runs after the instruments do:
vibrai generate --project my-song.vibrai
vibrai automation render --project my-song.vibraiOr have generate do it inline, as its last step:
vibrai generate --project my-song.vibrai --with-automationA target Vibrai can't resolve is no longer fatal. Each one is reported with the device it went looking for and the controls that device actually exposes, so you can see what to change.
One thing worth knowing: if a bounce fails and Vibrai can't put your arrangement clips back, the CLI exits with code 13, and the MCP response carries a data_loss message. That is the signal that clips were deleted and did not come back — check it rather than counting skipped entries.
Turn track numbering on and off
Ableton displays a leading # in a track name as that track's position, so # Bass shows up as 1 Bass. Vibrai could write that token but had no way to remove it, which meant a numbered set had to be renamed track by track.
vibrai track auto-number offIt sweeps every track in the open set. Turning it off strips a leading number only when that number matches the track's own position, so a track you named 808 Bass is left alone. Add --persist to make it the project's default. On MCP it's set_track_auto_numbering.
Where a project file lands by default
This one changes what an existing command does. Leave out --project and Vibrai used to reach for Untitled.vibrai. It now uses the name of the directory you're working in — so in ~/Music/dawn-chorus you get dawn-chorus.vibrai.
If you have projects named Untitled.vibrai, commands that used to find them won't any more. Rename the file, or point the command at it explicitly. Where Vibrai can tell that's what happened, the error says so.
Also fixed
- The install guide described a command that doesn't exist.
vibrai install statuswas never real, and the guide claimed the.pkgregisters the MCP server with Claude Desktop automatically. It doesn't. Claude Code now gets its own instructions rather than reusing Claude Desktop's. generate --create-missing-tracksno longer duplicates a track that's sitting right there. Reordering or rebuilding a set moved the track ids a project had remembered, the match missed, and Vibrai built a second copy alongside the original. It now finds a bound track by the name it saw, and writes the resolved ids back to the project file so the next run starts from the truth.vibrai uninstall --user <name>now removes that user's Claude Desktop entry and app data. Uninstall re-runs itself with elevated permissions when it needs to remove program files, and those two steps were reading the wrong home directory as a result — reporting success while leaving your files exactly where they were.- The first-song and genre-song wizards apply automation again, and tell you what landed. Moving automation out of
generateleft the wizards writing none of it, and saying nothing about it. - The session journal records the command that actually ran. Seven flags were being dropped from recorded assistant calls, leaving a shorter command that still looked plausible.
vibrai shellshows up invibrai --helpand in the published reference. It always worked — it was just invisible to everything that documents it.
All merged pull requests
What's Changed
- docs(marketing): name Vibrai in the V1 demo prompt (#397) by @gitizenme in cssllcio/Vibrai#569
- docs(marketing): copy-rewrite prompt library, guardrail-checked by @gitizenme in cssllcio/Vibrai#573
- docs: retire docs/user-guide.md, relocating what nothing else covered by @gitizenme in cssllcio/Vibrai#576
- docs: replace the guides' mechanical tables with a generated-reference pointer by @gitizenme in cssllcio/Vibrai#582
- docs: retire the two quickstarts, absorbed into docs.vibrai.com by @gitizenme in cssllcio/Vibrai#584
- test(docs): add validity gates for the user guides, and controls for the existing ones by @gitizenme in cssllcio/Vibrai#588
- feat(cli): register
shellas a real command so it reaches the catalogue by @gitizenme in cssllcio/Vibrai#591 - docs: CLAUDE.md said Done auto-closes issues; the workflow is disabled by @gitizenme in cssllcio/Vibrai#592
- docs(launch): T-5 runbook refresh, three stale-count fixes, and the server.json sync gate by @gitizenme in cssllcio/Vibrai#593
- --project defaults to the current directory name (#587) by @gitizenme in cssllcio/Vibrai#603
- feat(scale): honor a requested key/mode at generation time in one render by @gitizenme in cssllcio/Vibrai#601
- ci(release): remind the operator to delete the dry-run draft by @gitizenme in cssllcio/Vibrai#605
- docs(plan): v1.6.1 release spec + implementation plan by @gitizenme in cssllcio/Vibrai#581
- docs(plan): v1.6.1 absorbs #602; version rule waived for this release by @gitizenme in cssllcio/Vibrai#606
- Deploy Vibrai.mcpb to a findable path + discover the real Ableton User Library (#602) by @gitizenme in cssllcio/Vibrai#618
- docs(plan): v1.6.1 — #602 lands first, so Task 1 inverts by @gitizenme in cssllcio/Vibrai#620
- track auto-number: set Ableton's '#' numbering across the open set (#586) by @gitizenme in cssllcio/Vibrai#619
- docs(plan): v1.6.1 folds in #608 and #613 as Tasks 7 and 8 by @gitizenme in cssllcio/Vibrai#625
- docs(launch): T-3 status refresh, and a demo/release mismatch that blocks G1 by @gitizenme in cssllcio/Vibrai#624
- docs(plan): v1.6.1 Task 9 — live witness for #488 (fix already shipped as #511) by @gitizenme in cssllcio/Vibrai#631
- docs(launch): drop the key from the demo prompt, and defer G4 by @gitizenme in cssllcio/Vibrai#633
- docs(spec): drop the Board column from v1.6.1's scope table by @gitizenme in cssllcio/Vibrai#635
- feat(scale): derive chord degrees from the project's scale (mode-aware harmony) by @gitizenme in cssllcio/Vibrai#636
- docs: make the install guide true (#578, #577, #579) by @gitizenme in cssllcio/Vibrai#637
- Split automation out of generate into its own phase (#596) by @gitizenme in cssllcio/Vibrai#630
- CI: skip build/test/coverage when every changed path is inert (#632) by @gitizenme in cssllcio/Vibrai#638
- fix(soak): isolate SelfCheck test from xunit's parallel-collection noise by @gitizenme in cssllcio/Vibrai#640
- Cut GraphQL rate-limit cost of project-board lookups by ~30-100x by @gitizenme in cssllcio/Vibrai#644
- Verify the CI inert-path skip against real events (#639) by @gitizenme in cssllcio/Vibrai#641
- fix(ci): the inert allowlist skipped tests that read sessions/*.vibra...