Docs · 06
Export and stems
Four ways out, and a stem kit that loops without clicking.
The Export tab downloads the current song four ways:
| Format | What you get |
|---|---|
| Code | The generated .strudel source |
| WAV | One loop-ready mix file |
| Stems | The game stem kit below |
| Full | One zip: code/ (source plus a reopenable .loom.json), wav/ (mix), stems/ (per-layer WAVs) and the manifest |
The stem kit
Engine-agnostic on purpose: a mix WAV, per-layer stem WAVs, the generated source, and a
manifest.json carrying
- tempo,
- sample-exact loop points, and
- the arrangement matrix.
It imports into Unity, FMOD or Wwise without a conversion step, because the awkward parts — where the loop actually is, and which layer is meant to be playing when — are data in the manifest rather than something you re-derive by ear.
Loops that do not click
Stems render over the loop region you set in the timeline. The fold tail mode sums the
ringing reverb or delay tail back into the loop head, so a looping stem neither clicks at the seam
nor swallows its own reverb on the wrap.
That is the difference between a stem you can drop into an engine and a stem you have to edit first.
Rendering happens in a real audio context
Offline rendering needs OfflineAudioContext and AudioWorklets, so it runs in the browser rather
than on a server — which also means nothing about your song is uploaded to render it.
From the command line
The same document, checks and renderers run headlessly, so a build or an agent can ship a song without the GUI:
strudawl vocab # methods the node registry models
strudawl new song.strudel --name "Sunken Choir"
strudawl check song.strudel # import, round-trip, evaluate, onsets
strudawl inspect song.strudel # tempo, loop, layers, motifs
strudawl export song.strudel --out dist/export --what wav
export drives a headless Chrome against a temporary dev server for the same reason: the render
path is the browser’s, and using the real one is how the CLI and the UI stay honest with each
other.