Reference
Manual.

A complete description of Brume's synthesis engines, modulation, effects, and Lua scripting surface.

Overview

Brume is a multi-timbral instrument built on a CM5 reference platform. It runs four synthesis engines across four independent parts, each with six voices of polyphony (24 total), a state-variable filter per voice, dedicated modulation routing, and a shared effects chain. The entire interface runs on a 10.1-inch touchscreen.

The four engines correspond to four distinct approaches to electronic sound design: a six-operator FM engine with twelve data-driven algorithm topologies and a per-voice FM-index envelope; an additive harmonic engine with spectral scanning; a triangle-core timbral engine with wave-multiplier shaping; and a granular engine that generates pitched clouds of micro-oscillator grains.

Character

Brume runs four synthesis engines with a shared voice tail (state-variable filter, amp envelope, modulation router), so patches stay coherent across very different sources. Each engine has its own mechanism for continuous spectral change: algorithm routing and per-voice FM-index envelopes in FM, a scanning window in Harmonic, cascaded wavefolding in Timbral, grain scatter in Granular. No samples sit anywhere in the signal path; every voice is generated from live math.

The lineage worth naming is the Buchla 259 and Serge wavefolder tradition, the DX family’s phase-modulation surface, and the patch-on-a-small-computer approach of Norns and Plaits, rendered in software and unified under a single touchscreen. The default transition shape is Caffeinated, a pseudo-random walk, which sets the bias for the whole instrument: engines reveal themselves over tens of seconds rather than on first press, and loops rarely repeat quite the same way.

Interface

The top menu bar provides access to all pages: the four engine mode tabs (FM, HARMONIC, TIMBRAL, GRANULAR) on the left, and navigation pages (MOD, MIX, MIDI, SYS, LIBRARY, SCRIPT) on the right. Tapping a mode tab selects that engine for editing on the synth page.

Each synth page reflects live engine state. Parameter readouts update as values change, the signal-flow panel traces the shape of each box's input and output, and the MOD page shows LFO phase and sequencer positions as they advance.

Signal path

FM Oscillator

The FM engine is a six-operator phase-modulation synthesizer in the DX7 / Digitone lineage. Each operator is a sine wave; twelve data-driven algorithms determine which operators modulate which, and which are summed into the filter as carriers. A global FM index scales modulator contributions uniformly; a per-voice index envelope lets each note's FM depth decay independently, so a fresh attack rings brightly while held notes settle into their sustained partials, and a chord stab hit mid-sustain never re-brightens the already-ringing voices.

ALGO tab: topology and feedback

RATIOS tab: per-operator frequency

LEVELS tab: per-operator output and modulation

MOD tab: FM index and per-voice index envelope

Harmonic Oscillator

The Harmonic engine generates sound through additive synthesis, combining eight individually controllable harmonics with spectral shaping tools. A Gaussian scanning window sweeps across the harmonic series, isolating or blending partials as its center and width change.

SCAN tab: spectral scanning and waveform morph

Timbral Oscillator

The Timbral engine starts from a triangle-wave core and shapes it through a wave-multiplier circuit that transitions from soft saturation to cascaded wavefolding as the timbre control increases. An expanded symmetry parameter tilts the triangle core before it enters the shaper.

SHAPE tab: wave multiplier and feedback

Granular Oscillator

The Granular engine generates pitched clouds of micro-oscillator grains: short bursts of waveform output (1–500 ms) that overlap to produce evolving textures. Unlike sample-based granular systems, Brume synthesizes each grain from scratch.

CLOUD tab: grain generation

SVF Filter & Envelope

Each voice includes a state-variable filter operating in lowpass mode, with a dedicated ADSR envelope that modulates the cutoff frequency. The filter and envelope parameters are identical across all four engines.

Modulation: LFOs and step sequencers

Each of Brume's parts has an independent modulation router with two LFOs and two step sequencers. These four sources can be assigned to any synthesis parameter through the MOD page.

Shape library · 24 transitions

Brume’s LFOs, step sequencer transitions, and modulation assignment response curves all draw from the same 24-shape library, ported from the Formfactor plugin. Each shape has a descriptive name (shown large) and its engineering enum name (shown below) for scripting and patch editing. The default shape is Caffeinated (ChaosHeavy), a pseudo-random walk chosen as the default because it’s the most musically surprising of the 24.

Mixer

The MIX page provides a four-channel mixer with horizontal faders for each part (FM, Harmonic, Timbral, Granular), along with mute and solo controls. Each part’s level defaults to 0.8 and can be adjusted from 0 to 1. Each part also has independent delay and reverb send levels that control how much of the signal reaches the shared delay and reverb buses. A master volume control governs the final output level before the limiter. All level changes are smoothed to prevent clicks.

Effects

The EFFECTS panel on the MIX page provides four processing stages organized as tabbed controls: Saturator, Chorus, Delay, and Reverb. Saturator and Chorus operate as inserts on the dry master bus, processing all parts equally. Delay and Reverb operate as send effects, where each part’s independent send level controls how much signal reaches the effect. This architecture follows the model used in hardware instruments like the Elektron Digitone, where a dry bass line can coexist with a heavily reverbed pad without one treatment bleeding into the other.

Saturator

Chorus

Delay

The stereo delay supports both free-running millisecond timing and tempo-synced musical divisions. When a sync division is selected, the delay time auto-calculates from the transport BPM. The delay uses cross-channel ping-pong routing with a damping filter in the feedback path to darken successive repeats.

Reverb

Four reverb algorithms are available, each built from networks of allpass diffusers and parallel comb filters with damped feedback. All algorithms share the same parameter set; the internal topology and delay lengths differ to produce distinct spatial characters.

MIDI

Brume receives MIDI over USB from any class-compliant device (control surfaces, keyboards, sequencers) and from the Meridian USB bridge to a host DAW (see below). All sources feed the same engine in parallel, so a controller plugged into a USB-A port and the DAW’s MIDI output over Meridian both reach Brume simultaneously without any routing setup. DIN 5-pin gear connects through any class-compliant USB-to-DIN bridge (e.g. iConnectMIDI4+).

The MIDI page has three sections: channel routing on the left (a part-centric list where each part shows its assigned MIDI channel; tap the channel box to cycle through CH 1–16 or NONE), CC mapping in the middle (the LEARN workflow plus the list of persisted CC→parameter bindings), and the clock controls on the right. Multiple parts can share the same channel for layered playback, and a single channel can be reassigned at any time without stopping playback.

Note-off messages use a promiscuous release strategy: when a note-off arrives on any part, Brume also releases that note on all other parts. This prevents stuck notes when channel assignments change during a performance. MIDI CC messages 120 (All Sound Off) and 123 (All Notes Off) are recognized and release all active voices on the targeted part.

CC Mapping: LEARN workflow

The CC MAPPING panel binds incoming MIDI CCs to Brume’s synthesis parameters. Brume ships with sensible defaults (CC 1 → Filter Cutoff, CC 2 → Filter Resonance, CC 7 → Master Volume, CC 11 → Filter Envelope Depth, plus a few part-specific bindings), and the LEARN workflow lets you add or override any binding directly from the touchscreen. No keyboard required.

The flow has two states:

Transport & Clock

The CLOCK window on the MIDI page controls Brume's internal transport, which drives tempo-synced delay divisions and step sequencer timing. Three clock modes determine how the transport derives its tempo:

The BPM slider ranges from 20 to 300 and affects all tempo-dependent features: delay sync divisions, step sequencer beat triggers, and future arpeggiator patterns. When the clock is in Sync mode, the BPM display shows the estimated tempo from the incoming MIDI clock source.

Controllers

Brume supports external hardware control surfaces through two independent paths. Recognised surfaces are identified by their USB / ALSA port name on connect and get a built-in binding tailored to the actual Brume UI, with no configuration step. Any other MIDI controller can still be bound through the MIDI Learn flow on a CC-by-CC basis. The two paths coexist: a recognised surface does not block Learn from working on other controllers connected at the same time.

The tradeoff: a built-in binding covers the full surface out of the box but is fixed by the firmware; MIDI Learn is fully user-defined but scales one CC at a time. Power users can also reach the Lua scripting layer (see Extending Brume with Lua) to define per-CC behaviour that neither path provides.

Supported surfaces

Brume ships built-in support for two control surfaces: the Korg nanoKONTROL2 and the Novation Launch Control XL 3. Both are recognised on connect by their ALSA port name, then routed around the MIDI Control Matrix directly to the UI. A screen-follows binding maps the top encoder / knob row to the active sub-tab’s parameters, so switching engines or sub-tabs silently rebinds those controls to whatever is on screen.

The Korg nanoKONTROL2 is detected by the substring nanokontrol2 in the port name. Eight knobs and four faders cover the active sub-tab plus the MIX and MOD pages; Track and Marker buttons cycle engines and sub-tabs respectively.

The Novation Launch Control XL 3 is detected by the substring lcxl3 in the port name (or launch control xl on platforms that report the full product name). The Mk3 exposes four ALSA ports per device; only the surface MIDI port is bound, with the DAW (HUI/Mackie) and DIN passthrough siblings ignored.

Bring your own controller

Any controller not in the recognised-surfaces list works through MIDI Learn on the MIDI page. Tap LEARN, turn a knob or press a button, then pick a destination from the binding card (see the CC Mapping: LEARN workflow section for the LISTENING and DETECTED states walked through). Each binding persists until removed. Because Learn runs at the Control Matrix layer, it is completely independent of the engine on screen and of the recognised-surface path.

To add a new recognised surface at the code level, three small edits cover it:

The protocol layer (crates/app-protocol/src/lib.rs) already carries EngineToUi::ControllerCc and EngineToUi::ControllerNote with a kind field, so no additional message variants are needed for the common case of routing a new surface through the existing screen-follows logic. Custom behaviour that escapes the screen-follows model (a pad grid triggering chords, for example) is easiest to implement directly in the UI branch that handles that surface’s kind.

Meridian: MIDI and Audio to your DAW

Meridian is Brume’s integrated audio-and-MIDI bridge to a host computer, comparable in role to Elektron’s Overbridge for the Elektron range but built on open USB class-compliant standards so it works on Mac, Windows, and Linux without proprietary drivers. A single USB cable carries 8-channel audio out, bidirectional MIDI, and MIDI clock simultaneously.

In a DAW, arm one or more audio tracks with Brume’s capture as the input, route MIDI out from a track to Brume’s MIDI port, and Brume behaves as a first-class external instrument just like a Prophet or Moog patched into a multi-channel audio interface, with the additional convenience that it’s all on a single cable.

Incoming notes, CC, and MIDI clock over Meridian are parsed identically to other MIDI sources: they flow through the channel map, respect CC bindings, and drive the Sync clock mode. Audio output is structured for multi-track DAW workflows by default.

Per-part stems (8 channels)

Each of Brume’s four parts writes its own dry mono signal to a dedicated stereo channel pair on the USB capture endpoint:

Stems are dry: no master saturation, chorus, delay, or reverb. The intent is that DAW users already have better plugin FX than anything Brume ships internally, and recording dry preserves total flexibility. Brume’s master FX chain still computes for the local monitoring path (HDMI / DAC) so your touchscreen monitoring still sounds finished, but the USB stems are clean. The SYS page includes a compact channel-mapping reference (Ch 1-2 • FM / 3-4 • Harmonic / 5-6 • Timbral / 7-8 • Granular) so you can cross-check your DAW’s input picker without leaving the device.

The mapping between channel pair, Brume part, and the spatial label the DAW will display:

Use this when wiring input tracks in the DAW, or as the source of truth when performing the one-time channel rename to “FM”, “Harmonic”, and so on. The same mapping is also available on the device itself in the SYS page, collapsed to save space.

Meridian expands in capability over firmware releases. Already shipped: 8-channel per-part stems, bidirectional MIDI with clock, the channel-mapping SYS reference. Active follow-ons: a USB-NCM virtual network interface for the brumectl companion CLI, optional stripping of the UAC2 Feature Unit so the macOS volume slider disappears for bit-perfect passthrough.

Library

The LIBRARY page holds two kinds of recallable state: patches (a single engine's parameter state, or a single FX chain snapshot) and perfs (a whole-instrument snapshot containing all four engines' patches plus the FX chain plus mixer state). The mode tabs at the top switch between the FM, HARMONIC, TIMBRAL, GRANULAR, and FX patch browsers, plus a PERF tab for the whole-instrument snapshots.

Tapping SAVE captures current state for the active tab. On a patch tab (FM / HARMONIC / TIMBRAL / GRANULAR / FX) this writes just that engine's or the FX chain's parameters. On the PERF tab it writes the full instrument: every part's patch, the FX chain, the mixer levels and sends. Each row in the list has explicit LOAD and DELETE buttons; LOAD applies the saved state to the engine, DELETE removes the file from disk. Loading a patch switches the display to that engine's synth page so the slider positions visibly snap to the loaded values; loading a perf applies every part + FX + mixer in one batch, shows a centered LOADED PERF confirmation, then drops you on the first populated engine's page.

Every patch and perf file carries a small metadata envelope alongside its parameters: name, tags (the engine mode is auto-inserted on save), created_at and modified_at timestamps (ISO 8601 UTC), the Brume version that wrote the file, and optional author / description / notes fields. Unknown JSON fields are preserved on save-reload round-trips, so files written by a newer Brume don't lose data when read by an older binary. Both patch and perf schemas are versioned; new fields arrive as optional additions rather than breaking rewrites.

A perf embeds copies of each part's patch state (not references) so rename or delete of a source patch can't silently break a perf. Each embedded slot carries a non-authoritative source_patch breadcrumb for UI context, but that name is never consulted at load time; the embedded params are the source of truth.

System

The SYS page is Brume’s diagnostic and configuration surface. Every value on the page is read live from the running system; nothing is hardcoded. Plug in a different display, swap controllers, change sample rate, switch audio outputs, and SYS reflects it immediately. Sections are accent-colored: green = audio, cyan = MIDI, orange = system, magenta = display.

Audio Output

The audio-output section picks where Brume’s master mix lands. Brume enumerates every ALSA card on the device (the USB Meridian gadget, the HDMI output through the touchscreen speakers, any DAC hat, and any USB audio interface plugged into a USB-A port) and renders one row per detected output. The active device shows in the section accent color with a filled dot and an “ACTIVE” label; alternate devices render below as tappable “OPTION” rows. Tapping an option tears down the current audio stream and reopens on the chosen device with a brief (~100–200 ms) silence gap. The choice persists to ~/.brume/settings.json and is restored at startup.

SAMPLE RATE shows the actual rate the audio backend opened the device at, typically 48 000 Hz on Meridian, HDMI, and any modern audio interface. FORMAT shows the engine’s internal sample format.

MIDI

DEVICE shows the connected MIDI input by its OS-reported name (e.g. nanoKONTROL2). PORTS lists every MIDI port currently feeding the engine, joined with “ + ” when multiple sources are attached; a USB control surface and Meridian’s f_midi endpoint commonly run side by side. With no MIDI device connected, both rows show a placeholder dash.

Hardware

Hardware diagnostics for the CM5 reference platform. TEMPERATURE reads from the CM5 thermal sysfs and updates once per second. MEMORY shows the in-use resident memory for the Brume process. UPTIME is system uptime since boot. ENGINE reports the configured polyphony layout (4 parts × 6 voices = 24 total).

Display

RESOLUTION is detected from the connected monitor at startup via GDK and used to compute the auto-fit zoom level. Brume is canvas-designed against a 1024×600 logical resolution and auto-scales to whatever panel you plug in (the reference 1920×1200 touchscreen runs at scale 1.875). FPS shows the animation frame-rate cap. TOUCH reads the connected touch input device’s OS-reported name, useful when troubleshooting input issues or confirming the touchscreen probed correctly at boot.

Extending Brume with Lua

Brume embeds a Lua 5.4 scripting engine. Scripts are loaded from ~/brume/scripts/ and managed through the SCRIPT page.

API reference

-- Part constants. Targets for every part-addressed call.
brume.FM        -- part 0
brume.HARMONIC  -- part 1
brume.TIMBRAL   -- part 2
brume.GRANULAR  -- part 3

-- Any parameter on any part (name is the ParameterId string)
brume.set_param(part, name, value)

-- Trigger notes; velocity is 0.0–1.0
brume.note_on(part, note, velocity)
brume.note_off(part, note)

-- Chord and scale helpers
local notes = brume.chord(note.C4, "maj7")

-- FM algorithm constants: normalized 0..1 tap values accepted by
-- the engine's Algorithm parameter, so they slot into set_param directly.
brume.set_param(brume.FM, "Algorithm", brume.ALG.FAN_IN)
-- Also: STACK DOUBLE TWIN TRIO FAN_IN BRANCH HYBRID ADDITIVE
--       PAIRS TOWER FUNNEL CHAIN

-- Declarative FM patch. Sets algorithm, per-op ratios + levels,
-- feedback, and FM index in a single call. Any field is optional.
brume.set_fm_patch(brume.FM, {
  algorithm = brume.ALG.HYBRID,
  ratios    = {1.0, 2.0, 3.01, 4.0, 5.03, 6.0},
  levels    = {0.6, 0.35, 0.22, 0.14, 0.1, 0.07},
  feedback  = 0.2,
  index     = 0.7,
})

Coroutine clock

clock.run(function()
  while true do
    brume.note_on(brume.TIMBRAL, note.C3, 0.4)
    clock.sync(1/4)  -- wait a quarter note
    brume.note_off(brume.TIMBRAL, note.C3)
    clock.sync(1/4)
  end
end)

Brumectl: companion CLI

brumectl is the host-side companion command-line tool for Brume: a single Rust binary you run on your workstation (Mac, Linux, or WSL) to install Brume onto a CM5, push binary updates, open a maintenance shell, and probe device vitals. It is scoped to Brume devices specifically; every subcommand assumes the device on the other end is running Brume.

A bare brumectl invocation prints help. Every action is explicit.

Commands

Global flags and environment

Two flags and two env vars apply to every subcommand that talks to a device:

• --host USER@HOST or $BRUME_HOST: SSH target. Defaults to brume@brume.local.
• -i PATH / --key PATH or $BRUME_SSH_KEY: SSH identity file. Falls back to ssh-agent / ~/.ssh/config.

The install subcommand resolves the brume aarch64 binary in this order: --binary PATH (CLI flag), $BRUME_BINARY (env var), local workspace cross-build under target/aarch64-unknown-linux-gnu/release/, user cache (~/.cache/brumectl/binaries/ on Linux, ~/Library/Caches/brumectl/binaries/ on macOS), then download from GitHub Releases for the matching brumectl version with SHA-256 verification. Pass --no-download to refuse the network fetch, or --force-download to re-fetch a cached entry.

Typical install flow

# First-time install onto a fresh Pi OS Lite CM5
brumectl -i ~/.ssh/id_brume_cm5 install

# Binary-only refresh (edit source → cross-build → push)
brumectl -i ~/.ssh/id_brume_cm5 install --update

# Preview the install without running it
brumectl -i ~/.ssh/id_brume_cm5 install --dry-run

The install runs in six phases: probe (SSH + sudo + arch + OS checks), apt (runtime packages), binary (/usr/bin/brume), configs (labwc / systemd / ALSA / cursor theme), autologin (tty1 auto-login as the install user), verify. --update skips apt + configs + autologin and just refreshes the binary, with a round-trip under 30 seconds.

Build

# From a clone of the brume repo
cargo build --release -p brumectl

# Resulting binary
./target/release/brumectl --help

Pre-built binaries for macOS arm64 and Linux x86_64 are published on every tagged release at GitHub Releases. The cargo build above is also supported and is the natural path for contributors working on brumectl itself.

How it talks to the device

Every subcommand except flash is a thin layer over SSH. The CM5 lives on your LAN (WiFi or Ethernet) and announces itself as brume.local via mDNS; brumectl uses the system ssh and scp binaries to connect, honouring your existing ssh-agent and ~/.ssh/config. No bespoke protocol, no API tokens, no pairing flow.

The flash subcommand is the exception: it talks to a bare CM5 over USB mass-storage via rpiboot before any operating system is on the device, then hands off to SSH after first boot.

Hardware compatibility

The reference rig is a Compute Module 5 on a CM5 IO board. That’s the platform Brume is regression-tested on and the only one where Meridian (USB audio + MIDI bridge to your DAW) works, because Meridian needs a CM5 IO board wired for USB peripheral mode on its USB_OTG pin; the Pi 5’s Type-C is wired host-only.

That said, brumectl install is platform-agnostic. If you already own a Raspberry Pi 5 (or a Pi 4 with at least 8 GB of RAM, or a Pi 400), you can run Brume on it: synth engines, MIDI input, HDMI audio, and the touchscreen UI all work on stock Pi OS Lite 64-bit. You lose Meridian and you’re off the regression-test path, but the instrument itself plays.

End of manual · rev dev · Aftertone & Signal