Racks, variations, songs

Racks

A rack is a complete wired graph + front-panel layout that can be activated and torn down as a unit. One project holds many racks , "Live Rig", "Studio Practice", "Synth Standalone", and the active rack is the one whose audio engine is running.

Switching racks tears down the old rack's plugins, hydrates the new rack's plugins (including their saved state), re-applies its performer layout, and resumes audio. In v1 this is a hard switch (audio drops for ~100-300ms). Crossfade-on-switch is on the v2 roadmap.

Rack-switch hooks:

• onRackChange(rack) in your script fires AFTER the new rack is audible. Use it to re-emit LED feedback to controllers (LEDs reset on each rack), refresh any state your script holds that's rack-specific, and log into Diagnostics so future-you knows why a setting changed.
• The rack picker in the top toolbar's right side lets the user switch manually. Hardware MIDI / Program Change can drive it via script.

Variations

A variation is a snapshot of parameter values WITHIN a rack, same graph, different settings. Variations are perfect for "this song wants the piano patch bright, that song wants it warm" without changing the actual wiring or front-panel layout.

Each variation captures every plugin parameter + every widget position. Switching variations applies the snapshot to all bound parameters without re-instantiating plugins (so it's fast and audio-continuous, no drop).

Variation-switch hooks:

• onVariation(v) in your script fires when the active variation changes. Useful for changing script-managed widget labels, updating LED feedback to reflect the new state, logging.

Songs / Song Parts / Setlists, v2

Not in v1

Songs, Song Parts, Setlists, and ChordPro lyrics are advertised on the corporate product page but are NOT in v1. The engine + UI work lands in v2. The hook surface (onSongPart) exists in the script's typings as a placeholder; it won't fire in v1.

When it ships:

• A song is an ordered sequence of song parts that share one rack. Each song part picks a variation (so verse / chorus / bridge can each have their own sound).
• A setlist orders songs for a show.
• A foot-controller's Program Change messages can drive song-part advance directly via onProgramChange or a dedicated onProgramChange(pc => songPart.activate(...)) helper.

For v1, use variations + onProgramChange in your script to get much of the same behaviour:

const pc = midi.input('Foot Controller');

pc.on('program-change', (m) => {
  // map PC numbers to variation names in your active rack
  const variations = ['verse', 'chorus', 'bridge', 'outro'];
  const name = variations[m.program];
  if (name) variation.activate(name); // v1 helper coming
});

Hardware abstraction within / across racks

Audio device + MIDI device bindings are project-scoped, not rack-scoped, one project = one rig configuration. Bring the project to a different rig:

1. Open the project on the new machine.
2. The engine warns about unmatched device names (e.g. "MIDI Mix not found").
3. In the back-canvas inspector for each midi-in card, pick the correct device from the dropdown.
4. Save. The project now plays on this rig.

The script doesn't change, it addresses by logical name. The bindings, wires, widget layouts also don't change.