From patch to sound
Every edit to your graph becomes a small DSP program: Patchwerk generates Cmajor source from your nodes and cables, JIT-compiles it in the background, and hot-swaps the audio without a dropout.
For plugin makers who want to know what happens between dragging a cable and hearing it.
Your patch is a program
When you connect an oscillator to a filter, you're not configuring a fixed engine — you're writing code with cables. Patchwerk translates your entire graph (every node, cable, modulation routing, and the voice count) into one Cmajor program, compiles it to machine code, and runs the result on the audio thread.
graph edit (add node, connect cable, undo…)
│ ~100ms debounce — a burst of edits costs one compile
▼
Cmajor source generated from your nodes + cables
│ same source as last time? → skip compile, just push values
▼
JIT compile on a background thread (UI and audio keep running)
▼
new program hot-swapped into the audio callback — no dropout
You can read the generated program yourself: ask the assistant for the patch source and it returns the exact Cmajor code the compiler sees. Compile error line numbers map directly onto it.
Why most edits feel instant
Patchwerk works hard to avoid paying the full compile price:
| Edit | What happens | Cost |
|---|---|---|
| Turning a knob | Value pushed straight to the running program | Free — no compile |
| Mod amount / depth tweak | Live value push | Free — no compile |
| Bypass or suspend a node | Live gate value push (most blocks) | Free — no compile |
| Re-creating a topology you had before (undo, redo, A/B-ing) | Compile cache hit | Near-instant (~10ms) |
| A genuinely new topology | Full JIT compile | Noticeable — up to a second or two |
Two mechanisms drive that table:
- The topology check. Source generation is deterministic — the same graph always produces byte-identical code. If the new source matches the last compiled one, the compiler is skipped entirely and only current values are pushed. Param changes never even reach this path; they go straight to live endpoints.
- The on-disk compile cache. Every compiled topology is cached on disk, keyed by the generated source. Revisit a shape your patch has had before — even across sessions — and the machine code is reused instead of rebuilt. That's why only the first compile of a topology is slow and repeats are near-instant.
Structural edits are also debounced by about 100ms, so pasting five nodes or holding undo collapses into a single compile instead of five.
Polyphony: your patch, cloned per voice
A synth patch doesn't run once — the per-voice part of it (oscillators, envelopes, voice filters) is cloned for every voice, 8 by default and adjustable from 1 to 16. Global blocks (reverb, delay, output metering) run once, after all voices are mixed.
Note Voice count is a multiplier on CPU for everything in the per-voice section. If a patch runs hot, dropping from 16 to 8 voices roughly halves the cost of the voice section; the global effects section is unaffected.
Patches with an audio input are effect patches and run as a single global chain — no voice cloning.
Bypass and suspend without a recompile
Every node can be set to active, bypass (dry pass-through), or suspend (silence). For nearly all blocks this is a live value pushed into the running program — toggling it is instant, with no compile and no dropout. A handful of blocks without a built-in gate fall back to rewiring the patch around them, which does cost a recompile.
Suspend silences a block but doesn't remove its CPU cost entirely; deleting the node does.
When the compile fails
A broken edit can't take your sound down — the previous program keeps playing until a new one compiles successfully. You'll see the failure in three places:
- The status pill on the canvas floating bar: green
running, ambercompilingorerror. - The console panel, which holds the full compiler message.
- The AI assistant, which reads the same compile status and the generated patch source — "fix the compile error" works without pasting anything.
Tip Compiled OK but hearing nothing? Patchwerk checks whether the audio device is actually processing after each compile and warns if it has stalled — check your audio device settings before suspecting the patch.
What costs CPU
Open the DSP performance popover on the canvas floating bar to see the engine status and a live DSP CPU percentage. Toggle Perf Mode to measure per-node CPU cost — each node gets a badge showing what it actually costs, measured on a background engine so your live audio is never disturbed.
Things that move the number most:
- Voice count — a linear multiplier on the per-voice section.
- Heavy blocks — reverbs, oversampled distortion, and long modulated delays dominate most patches.
- Suspended ≠ deleted — pruning unused nodes is the only true zero.
While you edit, Patchwerk compiles with optimization turned down so swaps stay instant; the trade-off is DSP that runs a few times slower than it could. Exported plugins are built fully optimized, so your finished plugin runs faster than the same patch does inside the editor.