Owning end-to-end product design for a node-based adaptive audio engine: how ELIAS 4 positions against Wwise and FMOD, how the Studio's interface is architected, and the design bets behind every screen.
Role note. I designed ELIAS 4 end to end in 2022: IA, core flows, the node editor, and the design system. This case study pairs that work with a retrospective read of the shipped product as it stands in 2026, competitors included.
Game audio middleware is a category dominated by two incumbents, Audiokinetic's Wwise and Firelight's FMOD, with Epic's MetaSounds emerging inside Unreal. Both incumbents are powerful and both carry decades of accumulated interface complexity: soundbank pipelines, rebuild cycles and steep learning curves that skew the tools toward audio programmers rather than the composers and sound designers who author the actual content.
ELIAS started life as a pure adaptive music engine and expanded after 2018 into a fully spatialized sound engine. ELIAS 4 is the product of that expansion: a complete middleware that keeps the adaptive-music DNA as its differentiator. The product's pitch is telling. It doesn't lead with feature count, it leads with "create more with less effort and less overhead." That's a UX claim, not a technology claim, and it defined my brief: the entire competitive strategy rests on interface and workflow quality.
The incumbents' weakness isn't capability, it's friction. Every major feature decision (no soundbanks, visual scripting, live editing, Python tooling) attacks a specific incumbent friction point.
We aimed the Studio squarely at composers and sound designers, and deliberately de-coupled authoring from programming skill. Programmers get a parallel path through APIs, wrappers and optional source access.
Author adaptive soundtracks with per-instrument rules, motifs, tonal stingers and musical transitions, without touching code or waiting on engineering for iteration.
Traditional middleware asks them to think in trigger logic and bank pipelines before they can hear a single musical decision play back in context.
"Close the loop between changing a sound and hearing it in the game."
Build spatialized soundscapes, parameter-driven logic and DSP chains through the node graph; test directly in the tool and live-tweak against a running game.
Audio logic buried in code or opaque event hierarchies makes behavior hard to read back, and impossible to hand to a non-programmer.
"I can build anything in here. I just need to see what I built."
Personas reflect the two authoring roles the product was built for, drawn from studio partners and community feedback during development. Quotes are illustrative voice.
Audio programmers are the third user: they integrate the C/C++ runtime with any engine (Unity and Godot ship out of the box), automate the designtime via Python, and customize a modular codebase. The shared job across all three is the same, and it is the slowest, most demoralizing loop in traditional middleware workflows: hear the change in context.
Attacks bank build and rebuild cycles that break flow every time content changes. The iteration loop collapses from minutes to seconds, and "fast workflow without soundbanks" is the headline feature, not a footnote.
Attacks audio logic buried in code or opaque event hierarchies. Signal flow, logic, parameters and DSP live on one sample-perfect node canvas that non-programmers can read and author.
Attacks the edit, export, build, launch, listen cycle. You connect to a running game session and swap files, mix and tweak with instant in-game updates.
Attacks closed black-box tooling that teams can't extend. Studios script their own tools and batch workflows against live project data, so the tool becomes a platform.
Notice what these four bets have in common: none of them is an audio feature per se. All four are workflow features. Spatialization, DSP and platform coverage are treated as table stakes; the differentiation budget is spent entirely on reducing time-to-feedback and lowering the skill floor.
Across every screen, the Studio holds a consistent four-zone layout, a structure any DAW or IDE user will recognize instantly, which is precisely the point.
Persistent tree grouping Patches, Music, Mixers and Assets, the four content types of the entire mental model. Everything you author lives in one of these buckets.
Document tabs hold patch graphs, arrangements and profiler views side by side. The graph canvas and the timeline share the same real estate, unifying sound logic and music as peer document types.
Contextual inspector for the current selection: node parameters, asset settings, transition rules. Selection-driven, so the canvas stays uncluttered.
Play and stop transport, meters and session state: the constant "can I hear it right now?" affordance that backs the fast-iteration promise.
The visual language is a restrained pro-audio dark theme with the brand magenta reserved for identity moments and selection accents, while functional color is spent on the type system of the graph: ports and wires are color-coded by signal type (audio, parameters, events, triggers). Color has a job here, it isn't decoration.
Familiarity as an onboarding strategy. I borrowed conventions from Blender nodes, Max/MSP and Unreal Blueprints deliberately. A target user has almost certainly used one of these, so the learning curve starts halfway up.
Typed, color-coded ports encode the data model in the UI itself. Users learn what connects to what by sight, cutting a whole class of trial-and-error errors.
Test-in-tool transport means the author never leaves the canvas to validate a change.
Node graphs punish scale. The dense patch already shows wire crossings. Without strong auto-layout, alignment tools and wire organization, large projects can decay into spaghetti, the classic failure mode of visual scripting.
Graph search was still open design debt when I left. At hundreds of nodes, find, jump and minimap become as important as the editing itself.
Encapsulation answers the spaghetti risk, and it doubles as a sharing primitive. Teams can build internal libraries of proven behaviors.
Same canvas, one level deeper. Entering a subgraph doesn't switch paradigms; the interaction model is fractal, which keeps the concept count low.
Breadcrumbs and depth orientation matter once subgraphs nest. How the Studio tells you where you are three levels deep is a make-or-break detail.
Variants without duplication. Configurations kill the copy-the-patch-and-change-three-values anti-pattern that silently forks logic and creates maintenance debt.
Divergence visibility. When two configurations of one patch behave differently, users need a fast answer to what exactly differs. A diff-style view between configurations would close that gap.
Adaptivity as first-class structure. Random segment selection, motifs and stingers are authored objects on the timeline, not code hidden behind the music.
The two-paradigm seam. Music flows can also be controlled from visual scripting. The handoff between timeline-thinking and graph-thinking is where composers are most likely to get lost.
An answer to black-box anxiety. We positioned ELIAS against opaque middleware, so the profiler had to render that claim as UI. Authors can watch culling, voice limits and performance respond to their choices.
Profiling next to authoring, not in a separate app, keeps the observe-then-adjust loop inside one window, consistent with the whole fast-iteration thesis.
Four content types, one canvas grammar, fractal subgraphs. Concept count stays low even as capability grows: the discipline most pro tools lose over versions.
No soundbanks, in-tool playback, live remoting, embedded profiling: every layer of the product shortens the same loop.
DAW timeline for composers, node graph for designers, IDE layout for everyone. Novelty is reserved for the genuinely new (adaptive rules, configurations); familiarity carries the rest.
No pay-per-ticket support, an open Discord, an AI-powered manual, onboarding on-site or by call. For pro tools, the help experience is part of the interface, and ELIAS prices it in.
The screens above show well-groomed graphs; shipping games produce ungroomed ones. Auto-layout, graph search, minimaps, wire management and strong diffing between configurations are the features that decide whether the visual-scripting bet survives contact with a 200-hour project.
Music flows can be driven from the timeline or from the graph. That flexibility needs an opinionated default path per persona, or the flexibility reads as ambiguity.
Wwise and FMOD win partly on tutorials, hiring pools and plugin ecosystems. ELIAS's counters (open Discord, generous support, Python extensibility, Unity and Godot integrations out of the box) are the right shape, but the candid "we're eager to help you integrate with Unreal" signals where the adoption friction currently sits.
In this category the demo is the argument: you have to feel the workflow to believe it. Getting people into the Studio quickly matters more than any comparison table.
I owned product design end-to-end: defined the information architecture and core flows, designed the node editor, and established the design system. The design work was a core asset in the successful funding round, and the design function scaled from one designer to a dedicated five-person team building on those foundations.
The designed product vision was central to securing investment for the ELIAS 4 build-out.
Design grew from a single designer to a dedicated 5-person team working inside the system I established.
IA, core flows, node editor interaction model and the design system shipped as the durable skeleton of the product.
Outcomes as credited during my tenure; funding specifics are the company's confidential information.
ELIAS 4's entire differentiation is the time between intent and audible result. Every feature either shortens that loop or gets treated as table stakes. That focus is rare and it's why the product story is legible.
The Studio innovates in exactly two places, adaptive music structure and the configuration system, and pays for that novelty with ruthlessly conventional everything else. Users have a fixed budget for learning; spend it where you differentiate.
Typed ports, four content buckets, subgraph contracts: the architecture is legible in the interface. When users can see the system's shape, they debug themselves.
Python scripting, source access, engine-agnostic APIs. Professional users adopt tools they know they can outgrow gracefully. Extensibility isn't a power feature, it's a trust feature.
ELIAS 4 is a case study in challenger UX: don't out-feature the incumbents, out-flow them, and make every screen prove it.
Screens © Elias Software / House of Elias.