Skip to content

Releases: cssllcio/vibrai-releases

Vibrai v1.7.3

Choose a tag to compare

@gitizenme gitizenme released this 06 Sep 18:23
7e5a588

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

Choose a tag to compare

@gitizenme gitizenme released this 03 Sep 00:03
7e5a588

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

Choose a tag to compare

@gitizenme gitizenme released this 02 Sep 19:58
7e5a588

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

Choose a tag to compare

@gitizenme gitizenme released this 01 Sep 18:15
7e5a588

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

Choose a tag to compare

@gitizenme gitizenme released this 29 Aug 06:55
7e5a588

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

Choose a tag to compare

@gitizenme gitizenme released this 22 Aug 23:34
7e5a588

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

Choose a tag to compare

@gitizenme gitizenme released this 22 Aug 05:35
141b932

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

Choose a tag to compare

@gitizenme gitizenme released this 19 Aug 15:36
141b932

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 version

It 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_index was reported raw and 0-based by notes set / notes add and their MCP siblings, while track_id beside 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 render emitted a raw Live track id, a convention belonging to the older automation apply. It now matches render_automation, which never had the ambiguity.
  • generate returned warnings: null when there was nothing to report, while plan returned [] for the same key. It is always an array now. Code branching on warnings === null will 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 update can 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

Full Changelog: cssllcio/Vibrai@v1.6.2...v1.6.3

Vibrai v1.6.2

Choose a tag to compare

@gitizenme gitizenme released this 16 Aug 19:41
141b932

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-Reverb

On 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 id

mix 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 Compressor

mix 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 alongside

The 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 Wander curve 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 for apply_automation_template the 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 vibrai warns when an older standalone install shadows it on PATH. The install would appear to succeed while vibrai kept 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

Read more

Vibrai v1.6.1

Choose a tag to compare

@gitizenme gitizenme released this 09 Aug 02:21
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

Read more