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), an SVF 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 dual-oscillator complex architecture with FM, AM, and wavefolding; 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 (SVF filter, amp envelope, modulation router), so patches stay coherent across very different sources. Each engine has its own mechanism for continuous spectral change: cross-FM feedback in Complex, 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 (COMPLEX, HARMONIC, TIMBRAL, GRANULAR) on the left, and navigation pages (MOD, MIX, MIDI, SYS, LIBRARY) on the right. Tapping a mode tab selects that engine for editing on the synth page.

Signal path

Complex Oscillator

Interactive illustration rendered in the browser — the on-device DSP has more subtlety, but the parameter behaviours follow the same shape.

OSC tab — Oscillator waveforms and frequency relationship

MOD tab — Modulation paths

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 & 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 preset 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 (Complex, 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-C 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.

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

The Korg nanoKONTROL2 is the shipped reference controller. Brume detects it on connect by matching the string nanoKONTROL2 in the ALSA port name, then routes its events around the MIDI Control Matrix directly to the UI, where a screen-follows binding maps every control to a current action. Because the binding follows what is on screen, switching engines or sub-tabs silently rebinds the knob row to the new visible parameters.

The Novation Launch Control XL 3 is a second planned reference surface (see the BOM entry on the landing page) and is in development. Once integrated it will expose a deeper mapping appropriate to its 24-encoder, 8-fader, 16-pad layout: each engine likely gets a full page of encoders with the Page Up / Down buttons handling tab switching, and the 16 pads become clip launchers or per-part arm targets. The detection hook will follow the same ALSA port-name pattern.

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

The flow has two states, both shown below on a cropped view of the CC MAPPING panel:

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 — USB-C to your DAW

A line you cross. 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-C 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 • Complex / 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 “Complex”, “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 provides preset storage and recall for each engine. Presets capture all oscillator, filter, and envelope parameters for a single part and are stored as JSON files on the device’s filesystem, organized by engine type. Mode tabs at the top of the library page switch between the Complex, Harmonic, Timbral, and Granular collections.

Tapping SAVE captures the current state of the active engine and writes it to disk using an atomic write-then-rename operation that survives unexpected power loss. Tapping a preset name in the list loads its parameters into the corresponding engine and switches the display to that engine’s synth page. Presets can be deleted with the × button beside each entry.

The preset format is versioned and uses optional fields for future expansion. Current presets store oscillator and filter parameters; future versions may include modulation scenes, effects chain state, and multi-part combinations without breaking compatibility with existing files.

System

The SYS page is Brume’s diagnostic and configuration surface. Every value on the page is read live from the running system — no hardcoded numbers. 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, plus 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 — 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 “—”.

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

-- Set any of the 52 synthesis parameters
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")

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. Everything the device can’t do for itself — flashing a blank CM5 from a raw eMMC state, probing live status, opening a maintenance shell, watching device vitals, pushing OS updates — lives here. It is a single Rust binary distributed alongside the instrument; you install it on the workstation you already use to power the device over USB-C. The status, shell, and watch verbs work on any Unix host; the flash wizard currently requires macOS (it shells out to diskutil and ioreg), with a Linux port planned.

The tool is scoped narrowly. It is not a general-purpose Raspberry Pi utility — every subcommand assumes the connected device is a Brume, and authorization is established by physical possession of the USB-C cable rather than any account or token. The default invocation drops into an interactive ratatui wizard for first-boot flashing; the other subcommands are one-shot SSH-backed probes designed to feel like local commands.

Commands

Build & install

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

# Resulting binary
./target/release/brumectl status

A Homebrew tap (brew install aftertonesignal/tap/brumectl) and direct GitHub release downloads are planned but not yet live. Until then the cargo build is the canonical install.

How it talks to the device

Brume exposes a USB Network Control Model (NCM) interface, so the moment you plug it into your Mac it appears as a USB-Ethernet peer with a stable link-local address and announces itself as brume.local over Bonjour on that interface only. Every brumectl subcommand other than flash is a thin layer over SSH to that address — no bespoke protocol, no API tokens, no pairing flow. The flash subcommand is the exception: it uses rpiboot to talk to the bare CM5 over USB mass-storage before any operating system is on the device, then hands off to SSH once the first boot completes.

End of manual · rev 0.9.2 · Aftertone & Signal