Stingers, Stems, and the Machinery Behind an Adaptive Score
Understanding that a game score has to adapt is the concept. Building one that actually works inside a middleware system — Wwise, FMOD, or a custom engine — is the craft. And the craft lives in three specific pieces of machinery: stingers, stems, and transitions.
Stingers Are Not Afterthoughts
A stinger is a short, one-shot musical event triggered by a specific action — a discovery, a hit landing, a door unlocking. It's easy to treat stingers as a minor add-on to the "real" score, written last and quickly. That's a mistake. Stingers are often the most-heard material in an entire game, because they fire every single time their trigger condition is met, sometimes dozens of times per session.
A good stinger does its job in well under a second: fast attack, a clear harmonic or timbral identity, and a decay that doesn't linger long enough to clash with whatever plays next. It also has to sit in the same tonal world as the underlying score without necessarily matching its exact key at the moment it fires — because the underlying score might be anywhere in its own harmonic movement when the trigger happens. Write stingers with too much harmonic specificity and they'll clash constantly. Write them with the right amount of ambiguity and they'll sit under almost anything.

Stems Have to Share a Spine
Vertical layering — the technique of stacking synchronized stems and muting/unmuting them by intensity — only works if every stem shares the same tempo, the same key center, and the same bar-aligned structure. This sounds obvious stated plainly, but it's the single most common technical failure in delivered game scores: a composer writes an "intense" layer that drifts slightly in tempo from the "calm" layer because they were produced at different times, and the two can't actually combine without a seam.
The practical fix is to build all stems from a single session with a locked tempo map from the start, exporting each layer as its own file at identical length and identical bar-one alignment — even if a given layer is mostly silence for long stretches. Silence that's correctly aligned is far more useful to a middleware system than a shorter file that's musically "cleaner" but doesn't line up.

Transitions Are Where Scores Fail in Practice
The theory of horizontal re-sequencing is simple: pre-composed segments crossfade based on game state. In practice, most interactive scores fail not in the segments themselves but in the transition regions between them — the two bars where one segment is fading out while another fades in, and the harmonic or rhythmic relationship between them was never actually checked.
The fix is unglamorous: build an overlap region into every segment — a few bars of tail that can crossfade against a few bars of head from any other segment the system might transition to — and actually audition every plausible transition pair before delivery, not just the ones that seem most likely to occur first.
None of this is about limiting a composer's expressive range. It's about building material with the structural honesty to survive a system that will use it in ways the composer can't fully predict. That same discipline — punchy, immediate, tonally ambiguous material that reads instantly — is exactly what a good stinger source needs to start from.
Presets for PolyBrute — Obsidian is a collection of patches exploring the hidden depths of Arturia's flagship analog synth — short-decay, high-character tones built to read in an instant. Explore it at sonalsystem.com
More on composition, sound design, and the business of music in the Frequencies archive.
