Adaptive runtime reference

Why this engine, for a game

• Deterministic. Same seed + same call timeline = the same score, bit for bit at the event layer — down to the humanized microtiming, which is a pure function of the seed, not a per-playback jitter. Replays and rollback resims stay in sync, soundtracks are testable in CI, and streamers are safe: every shipped sound is provenance-tracked and cleared.
• The music state lives in the game save. The whole state vector is a small chunk (save-state / load-state); restoring resumes the exact take.
• Near-zero cost. The event layer is integer-only; the render layer is a small fixed DSP set.
• Music as data. An instance can emit the raw event stream instead of audio — drive haptics, lighting, or your own synth from the score.

The mapping (game state → controls)

And the reverse flow — the game reading the score: each event's harmonic-tension lane is the tension trajectory, and a field-poll call streams the cascade's structure for visualization.

The musical clock. A frames-to-next-bar call is the beat-sync primitive: the number of your own output frames until the next downbeat reaches the listener — schedule a stinger on it, beat-match a gameplay event, or pre-warm the reveal a queued bar-quantized switch will land on (zero exactly on a boundary). A position call reads the output's zero-based musical position in the current take. Both are computed at the current effective tempo and self-correct after a tempo change, exactly like the switch boundary itself.

Musical transitions (the part middleware usually makes you build)

The bar-quantized pack switch is the built-in horizontal re-sequencing primitive: the current pack finishes its bar, the new pack's first tick lands exactly on the next downbeat, and the sample timeline never breaks. Dials, pins, Level, Tempo and Key carry over. It is replay-stable: the same request at the same musical position produces the same audio.

Inference-driven direction (the listener pattern). You do not have to wire a "combat started" event to get the mood move: the Unity director sample ships a regime listener — a small Hamilton filter over the same Markov-switching multifractal family the engine generates from — that infers the regime from one raw gameplay scalar's churn (danger, threat, arousal) and drives the bar-quantized switch through a debounced gate, so the score hears combat rather than being told. See it running in the browser at the live demo with the listener meter on; a calibration tool in the SDK fits the listener to a recorded playtest trace by maximum likelihood.

• The immediate variant re-anchors the take — a hard cut, the DAW-preset semantic. Use it for scene loads.
• For crossfades, run two instances (they are independent and cheap), drive them from the same host-tempo clock, and equal-power fade between their outputs in your mixer — two-instance layering is the intended pattern for vertical mixes too (calm bed + combat layer, fade by gameplay).
• On an event-driven instance a pending switch applies between calls at the bar boundary; observe the active pack through the registry index.

Audio integration

• Stereo: the stereo render call fills your left/right buffers with the pack's authored stereo image (per-voice pans + the pack's one shared room) at the sample rate you constructed with. Any block size; block-size independent.
• Mono: the mono render is the exact fold ½·(L+R) — handy for distant or diegetic sources you spatialize yourself.
• An instance is mono-driven or stereo-driven, and audio-driven or event-driven — the first call decides each split; use separate instances for separate jobs.
• Threading: engine calls are not thread-safe per instance — your audio thread owns the render; serialize parameter/state calls against it (a lock or a message queue), the same discipline as any plugin host. Multiple instances are fully independent.
• Sample-rate changes restart the take deterministically — treat a device switch as a musical restart or resume from a saved state chunk.

Determinism & save games

The humanized feel is deterministic too: the microtiming is a bounded, integer-exact function of the seed (a per-voice timing sub-cascade, not a per-playback jitter), so the exact groove survives a replay, a rollback resim, or a loaded save — where a non-deterministic humanizer cannot. Save the seed with the game save for a fresh-but-identical score, or the state chunk to resume the exact take, pins and all. Pin the engine version if your replays must survive engine updates — the event stream is bit-exact per version; rendered audio is tolerance-equal.

The scaffold registry

The registry calls enumerate the embedded packs — the launch packs (beat-driven, warm ambient, cinematic) and the rest of the shipped corpus, every pack held to the same ten quality invariants as the web product, including the spectral-structure gate (the 1/f onset-stream floor) — so a mood switch can never land on a pack that lost its multi-scale character. Artist adaptive-soundtrack packs ride the same registry.

Engine bindings

Thin, idiomatic bindings for the common engines ship with the SDK — a header-only C++ wrapper (the substrate for the others), a Unity package (P/Invoke + an AudioSource component), a Godot 4 GDExtension node, and an Unreal component. Each is a 1:1 wrapper over this interface, pinned to the C header symbol-for-symbol in CI. Start from the game developer start-up guide, or see the bindings overview.

What this is not (yet)

Engine-side state morphs (continuous interpolation between packs) are not built — use the two-instance crossfade. The bindings are reference-grade wrappers, not yet published SDK packages on each engine's store; that productization (and the counsel-reviewed runtime license going live) is gated on real demand — the waitlist is where that signal comes from.