Skip to content

Vibrai v1.6.1

Choose a tag to compare

@gitizenme gitizenme released this 09 Aug 02:21
· 2 commits to main since this release
141b932

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 Dorian

The 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 --reveal

The 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.vibrai

Or have generate do it inline, as its last step:

vibrai generate --project my-song.vibrai --with-automation

A 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 off

It 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 status was never real, and the guide claimed the .pkg registers 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-tracks no 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 generate left 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 shell shows up in vibrai --help and in the published reference. It always worked — it was just invisible to everything that documents it.
All merged pull requests

What's Changed

Full Changelog: cssllcio/Vibrai@v1.6.0...v1.6.1