What polec emits
IR, a WAV, an object file, a C header, a wasm module — one compiler, several useful outputs.
Anyone taking a patch out of the editor.
polec has one job with several endings. --emit= picks which.
--emit= | what you get |
|---|---|
ir | the intermediate representation, as text |
llvm | LLVM IR |
wav | a 32-bit float WAV, rendered offline |
object | a native object file |
header | the C header that drives it |
export | both — --out=x writes x.o and x.h |
web | an object and a JSON manifest, targeting wasm32 |
Choose by the next thing you want to do#
Use wav when you want to hear, inspect or share a render without a live
host. Use ir or llvm when investigating how a patch compiles. Use export
when a C or C++ program will call the DSP, and web when a browser runtime
will host it.
An object file is compiled DSP code, not an application or plugin by itself. It still needs a host to provide audio buffers, parameter values, state and any loaded samples. A header describes that contract for native code; a JSON manifest describes it for the browser runtime.
--emit=export — the one that ships#
./build/polec fx.pole --emit=export --out=fxWrites fx.o and fx.h. Link them into a plugin and Pole is not present at
run time: no JIT, no LLVM, nothing to install. The only thing the object
needs is libm, and with
--approx-math it needs less of
that.
The object is the same optimised module a JIT session would run. That is what makes an exported plugin bit-identical to what you were hearing in the editor, and there is a check that holds it to that rather than a claim that it ought to be.
--emit=web — the one that made this page#
./build/polec fx.pole --emit=web --out=fxWrites fx.o and fx.json. Targets wasm32 unless --target says otherwise.
Link the object with wasm-ld and the manifest tells a browser everything the
C header would have told C: entry symbols, parameter ranges, state size and
seeds, per-node state offsets, externals, handlers, event routes and buffer
offsets.
Nothing on the browser side parses the C header, and nothing should — a runtime that parsed C would break the day the header's formatting changed.
Cross-emitting#
--target takes a triple and --cpu a processor model:
./build/polec fx.pole --emit=export --out=fx --target=x86_64-pc-windows-msvc
./build/polec fx.pole --emit=export --out=fx --target=x86_64-unknown-linux-gnu --cpu=x86-64-v3--cpu defaults to apple-m1 on arm64 macOS — the oldest such machine — and
generic elsewhere. An x86-64 plugin that may assume AVX2 says
--cpu=x86-64-v3.