> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vibrai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Mixing

> Set-wide mixing: return tracks, bulk mix application, profile-driven placement advice, and the mixing-knowledge reference.

Set-wide mixing: return tracks, bulk mix application, profile-driven placement advice, and the mixing-knowledge reference.

## Command line

### `mix returns`

List the set's return tracks (the names --send accepts)

```bash theme={null}
vibrai mix returns
```

### `mix apply`

Apply a whole mix at once, keyed by part type

```bash theme={null}
vibrai mix apply --part <SPEC> --project <PATH>
```

<ParamField path="--part">
  Mix entry as part\_type=dB, optionally with pan and sends: pad=-12:pan=-0.3:send=A-Reverb=-9. Repeatable.
</ParamField>

<ParamField path="--project">
  Path to the .vibrai file (default: \<current-directory-name>.vibrai in the working directory). Without one, binding falls back to track-name hints.
</ParamField>

### `mix profiles`

List the available mix profiles

```bash theme={null}
vibrai mix profiles
```

### `mix suggest`

Suggest level, pan, depth and corrective moves per part type

```bash theme={null}
vibrai mix suggest --chains --techniques --profile <NAME> --part <PART_TYPE> --project <PATH>
```

<ParamField path="--chains">
  Also print the corrective EQ and compressor moves for each part.
</ParamField>

<ParamField path="--techniques">
  Also print the profile's technique blocks (compressor setup, serial vs parallel compression, harshness check, drum impact).
</ParamField>

<ParamField path="--profile">
  Mix profile to use (default: default). See `vibrai mix profiles`.
</ParamField>

<ParamField path="--part">
  Part type to include, e.g. bass. Repeatable. Omit to use the loaded project's parts, or the whole profile when there is none.
</ParamField>

<ParamField path="--project">
  Path to the .vibrai file (default: \<current-directory-name>.vibrai in the working directory).
</ParamField>

### `mix apply-profile`

Apply a mix profile's level, pan and depth to the open set

```bash theme={null}
vibrai mix apply-profile --reverb-return <NAME> --dry-run --profile <NAME> --part <PART_TYPE> --project <PATH>
```

<ParamField path="--reverb-return">
  Return-track name carrying the depth reverb, e.g. A-Reverb (see `vibrai mix returns`). Without it, level and pan are applied and depth is reported as a warning rather than written.
</ParamField>

<ParamField path="--dry-run">
  Report what would be written without writing it.
</ParamField>

<ParamField path="--profile">
  Mix profile to use (default: default). See `vibrai mix profiles`.
</ParamField>

<ParamField path="--part">
  Part type to include, e.g. bass. Repeatable. Omit to use the loaded project's parts, or the whole profile when there is none.
</ParamField>

<ParamField path="--project">
  Path to the .vibrai file (default: \<current-directory-name>.vibrai in the working directory).
</ParamField>

### `mix advice`

Look up mixing guidance: compression, reverb, low-end, tool choice

```bash theme={null}
vibrai mix advice [topic] --for <SUBJECT>
```

<ParamField path="topic">
  compression, reverb, low-end or tool-choice. Omit to list the topics.
</ParamField>

<ParamField path="--for">
  Narrow the topic: a compression source (kick) or part type (bd), or a reference entry (pre-delay, phase-cancellation).
</ParamField>

### `mix compress`

Write a source's compression starting points onto a compressor

```bash theme={null}
vibrai mix compress <track> <device> --for <SOURCE> --dry-run
```

<ParamField path="track" required>
  Track handle (trk\_42) OR 1-based number (1, 2, …) OR ordinal (first, second, …).
</ParamField>

<ParamField path="device" required>
  Device ID, 1-based chain position, or a name substring — the compressor to write to.
</ParamField>

<ParamField path="--for">
  Compression source: kick, snare, bass, vocal, guitar, piano — or a part type such as bd.
</ParamField>

<ParamField path="--dry-run">
  Report the writes without making them. The device is still read, so the skips are real.
</ParamField>

## MCP tools

### `get_track_mixer`

Read a track's mixer state: volume (both dB and Live's raw 0.0-1.0), pan, mute, solo, arm, and every send with its return-track name. Address the track by its liveset\_id handle from list\_tracks (e.g. trk\_42).

```json theme={null}
{
  "tool": "get_track_mixer",
  "arguments": {
    "liveset_id": "<String>"
  }
}
```

<ParamField path="liveset_id" type="String" required>
  Track handle from list\_tracks, e.g. "trk\_42". Copy verbatim; not a position number.
</ParamField>

### `set_track_mixer`

Set any subset of a track's mixer state. Omitted fields are left untouched. Volume takes EITHER volume\_db (preferred, e.g. -6) OR volume\_raw (Live's 0.0-1.0) — passing both is an error. A fader runs to +6 dB (unity at raw 0.85); a send runs to 0 dB. Sends are addressed by return-track name as "name=dB" pairs, e.g. \["A-Reverb=-12"]. Returns the post-write state, so the reported volume is what actually landed rather than what was requested.

```json theme={null}
{
  "tool": "set_track_mixer",
  "arguments": {
    "liveset_id": "<String>",
    "volume_db": "<Nullable`1>",
    "volume_raw": "<Nullable`1>",
    "pan": "<Nullable`1>",
    "mute": "<Nullable`1>",
    "solo": "<Nullable`1>",
    "arm": "<Nullable`1>",
    "sends": "<String[]>"
  }
}
```

<ParamField path="liveset_id" type="String" required>
  Track handle from list\_tracks, e.g. "trk\_42". Copy verbatim; not a position number.
</ParamField>

<ParamField path="volume_db" type="Nullable`1">
  Volume in dB, e.g. -6.0. Maximum +6. Mutually exclusive with volume\_raw.
</ParamField>

<ParamField path="volume_raw" type="Nullable`1">
  Volume as Live's normalized 0.0-1.0 (0.85 is unity). Mutually exclusive with volume\_db.
</ParamField>

<ParamField path="pan" type="Nullable`1">
  Pan, -1.0 (hard left) to 1.0 (hard right).
</ParamField>

<ParamField path="mute" type="Nullable`1">
  Mute the track.
</ParamField>

<ParamField path="solo" type="Nullable`1">
  Solo the track. Solo is additive — Live does not clear other soloed tracks.
</ParamField>

<ParamField path="arm" type="Nullable`1">
  Arm the track for recording. Group, return and master tracks cannot be armed.
</ParamField>

<ParamField path="sends" type="String[]">
  Send levels as "return\_name=dB" pairs, e.g. \["A-Reverb=-12", "B-Delay=-18"]. Use list\_returns to see the available names.
</ParamField>

### `apply_mix`

Apply a whole mix in one call, keyed by part type. Each entry is "part\_type=dB" (e.g. "bass=-6"), optionally with pan and sends: "pad=-12:pan=-0.3:send=A-Reverb=-9". Resolves part types to tracks via the loaded project when there is one (exact), or track-name hints when there isn't (heuristic) — the result reports which path ran. Part types with no matching track come back as warnings, not errors.

```json theme={null}
{
  "tool": "apply_mix",
  "arguments": {
    "parts": "<String[]>",
    "project_path": "<String>"
  }
}
```

<ParamField path="parts" type="String[]" required>
  Mix entries, e.g. \["bass=-6", "lead=-3", "pad=-12:send=A-Reverb=-9"].
</ParamField>

<ParamField path="project_path" type="String">
  Path to the .vibrai project to bind part types against (defaults to \<current-directory-name>.vibrai in the working directory). When no project is found, binding falls back to track-name hints and says so.
</ParamField>

### `list_returns`

List the set's return tracks with their index and name. These names are what set\_track\_mixer and apply\_mix accept in their sends arguments.

```json theme={null}
{
  "tool": "list_returns",
  "arguments": {}
}
```

### `list_mix_profiles`

List the available mix profiles. A profile carries starting-point placement (level, pan, depth) per part type plus corrective EQ and dynamics advice. Drop a file at \~/.vibrai/mix-profiles/\<name>.yaml to add or shadow one.

```json theme={null}
{
  "tool": "list_mix_profiles",
  "arguments": {}
}
```

### `suggest_mix`

Suggest a mix without changing anything. Returns, per part type: a starting level in dB, a pan position, a depth tier and the reverb send that expresses it, plus the corrective EQ moves and compressor settings that belong on that part — each with the reason attached. Also returns the profile's global rules (headroom, the 2-5 kHz harsh band, return-track guidance) and its technique blocks (serial vs parallel compression, compressor setup, harshness check). Part types come from `parts` if given, else from the loaded project, else the whole profile. The EQ/compressor numbers are DISPLAY units and are advice, not a write: apply them with set\_device\_param and check the display\_value it reports back. Use apply\_mix\_profile to apply the level/pan/send half for real.

```json theme={null}
{
  "tool": "suggest_mix",
  "arguments": {
    "profile": "<String>",
    "parts": "<String[]>",
    "project_path": "<String>"
  }
}
```

<ParamField path="profile" type="String">
  Profile name (default: "default"). See list\_mix\_profiles.
</ParamField>

<ParamField path="parts" type="String[]">
  Part types to advise on, e.g. \["bass", "lead", "hi\_hat"]. Omit to use the loaded project's parts, or the whole profile when there is none.
</ParamField>

<ParamField path="project_path" type="String">
  Path to the .vibrai project whose part types to advise on (defaults to \<current-directory-name>.vibrai in the working directory).
</ParamField>

### `apply_mix_profile`

Apply a mix profile's PLACEMENT to the open set: level and pan per part type, plus a reverb send when reverb\_return names a return track. Part types resolve to tracks exactly as apply\_mix does — through the loaded project when there is one, by track-name hint when there isn't — and the result says which path ran. The profile's EQ and compressor advice is NOT applied; suggest\_mix reports it so you can apply it with set\_device\_param, where Live reports back the display\_value that landed. Pass dry\_run to see what would be written.

```json theme={null}
{
  "tool": "apply_mix_profile",
  "arguments": {
    "profile": "<String>",
    "parts": "<String[]>",
    "reverb_return": "<String>",
    "project_path": "<String>",
    "dry_run": "<Boolean>"
  }
}
```

<ParamField path="profile" type="String">
  Profile name (default: "default"). See list\_mix\_profiles.
</ParamField>

<ParamField path="parts" type="String[]">
  Part types to apply, e.g. \["bass", "lead"]. Omit to use the loaded project's parts, or the whole profile when there is none.
</ParamField>

<ParamField path="reverb_return" type="String">
  Return-track name that carries the depth reverb, e.g. "A-Reverb" (see list\_returns). Without it, level and pan are applied and depth is reported as a warning rather than written.
</ParamField>

<ParamField path="project_path" type="String">
  Path to the .vibrai project to bind part types against (defaults to \<current-directory-name>.vibrai in the working directory).
</ParamField>

<ParamField path="dry_run" type="Boolean">
  Report what would be written without writing it.
</ParamField>

### `get_mix_advice`

Look up Vibrai's mixing knowledge. Topics: "compression" (compressor starting points per source, plus 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), "tool\_choice" (whether a problem wants EQ, compression, dynamic EQ or automation). Call with no topic for the index. Narrow with subject — a compression source ("kick") or part type ("bd"), or a reference entry ("pre\_delay", "phase\_cancellation"). This is guidance with defaults, not measurement: \~/.vibrai/mix-advice/\<topic>.yaml overrides any of it.

```json theme={null}
{
  "tool": "get_mix_advice",
  "arguments": {
    "topic": "<String>",
    "subject": "<String>"
  }
}
```

<ParamField path="topic" type="String">
  One of compression, reverb, low\_end, tool\_choice. Omit for the topic index.
</ParamField>

<ParamField path="subject" type="String">
  Narrows the topic: a compression source ("kick") or part type ("bd"), or a reference entry id ("pre\_delay").
</ParamField>

### `apply_compression_preset`

Write a source's compression starting points — Attack, Release and Ratio — onto a compressor already loaded on a track. Source is a name ("kick", "vocal", "bass", "snare", "guitar", "piano") or a part type that maps to one ("bd", "snare", "bass"). Threshold is deliberately NOT written: it depends on the incoming level, which no table can know. A parameter the device does not expose, or whose units clearly differ (a Release choice list in seconds against a millisecond table), is skipped with a warning rather than clamped — the call fails only if nothing at all is writable. Pass dry\_run to see the writes without making them. Use get\_mix\_advice for the ranges these starting points sit in.

```json theme={null}
{
  "tool": "apply_compression_preset",
  "arguments": {
    "liveset_id": "<String>",
    "device_id": "<String>",
    "source": "<String>",
    "dry_run": "<Boolean>"
  }
}
```

<ParamField path="liveset_id" type="String" required>
  Track handle from list\_tracks, e.g. "trk\_42". Copy verbatim; not a position number.
</ParamField>

<ParamField path="device_id" type="String" required>
  Device ID, 1-based chain position, or a name substring — the compressor to write to.
</ParamField>

<ParamField path="source" type="String" required>
  Compression source: kick, snare, bass, vocal, guitar, piano — or a part type such as "bd".
</ParamField>

<ParamField path="dry_run" type="Boolean">
  Report the writes without making them. The device is still read, so the reported skips are real.
</ParamField>