MetaSounds is a node-based DSP graph inside Unreal Engine that generates audio in real time rather than triggering pre-recorded files. It looks similar to Blueprints on the surface, but it operates on audio data at the sample level, which is what makes it capable of producing sounds that respond continuously to gameplay state rather than just playing one of several pre-recorded clips.
The practical value of that capability depends on what you are building. A game that plays a fixed set of pre-recorded sound effects does not need MetaSounds. A game where a footstep changes character based on terrain, speed and accumulated wear, or where a weapon sound responds to upgrade level and remaining ammo, is a different problem. Sound Cues play prepared clips with some logic on top. MetaSounds generate the sound itself.
The synthesis principles behind the sounds themselves are covered in How to Make Game Sound Effects and How to Generate Procedural Sound Effects in Godot with Code. This article is about the MetaSounds implementation.
How MetaSounds Differs from Sound Cue
A Sound Cue is a playback container. It selects among prepared audio clips, applies some processing, and handles basic logic like randomization and crossfading. The Sound Cue decides which sound to play; it does not create the sound.
A MetaSound Source is a sound generator. It contains a graph of audio nodes that produce a signal from oscillators, noise, filters, envelopes and modulation. The output is a stream of samples computed at runtime. There is no audio file involved unless a Wave Player node is placed in the graph.
This distinction has practical consequences. A Sound Cue that contains three footsteps can play one of three recordings. A MetaSound that contains three footsteps can play one of three recordings, then modify each one by adjusting pitch, filtering and envelope based on parameters from the game. The three clips become the raw material for a larger range of outcomes.
The performance profile is different as well. MetaSounds run on the audio thread and process samples block by block, which gives lower playback latency than Sound Cue in many cases. The cost is that a complex MetaSound graph consumes more CPU than a simple Sound Cue playing a pre-recorded clip, because the audio is being computed rather than read from memory. On resource-constrained platforms, the tradeoff is worth measuring rather than assuming.
Creating a MetaSound Source
In the Content Browser, right-click and choose Audio, then MetaSound Source. This creates a new MetaSound asset and opens the MetaSound Editor, which is where the node graph is built.
The default setup is a one-shot mono sound. The Interfaces panel on the left contains a UE.Source.OneShot interface, which means the sound plays once and then stops. This is correct for a footstep or an impact. For a looping sound like ambience or a continuous machine hum, remove that interface so the sound can persist.
The output format is controlled from the MetaSound button in the toolbar. Changing the output format from Mono to Stereo replaces the single Out Mono node with separate Out Left and Out Right nodes, which allows independent control of each channel. For a spatialized 3D sound effect, mono is usually the correct choice, because the engine handles the positioning. For a non-spatialized ambience, stereo is what gives the sound width.
Building a Procedural Footstep Graph
A footstep is a good starting point because it is short, repetitive, and benefits from variation. The graph below produces a footstep that changes pitch and character with each playback, using only a single recorded impact as the source material.
The nodes are connected in a chain from the audio source to the output. Start with a Wave Player node and assign a recorded footstep clip to it. Connect the audio output of the Wave Player to a One-Pole Low Pass Filter, then to the output node.
The variation comes from two exposed parameters. First, a Random (Float) node generates a value between 0 and 1 each time the sound plays. Feed that value into a Map Range node that scales it to a pitch range, such as 0.92 to 1.08. Connect the scaled value to the pitch input of the Wave Player. Second, feed the same random value into a second Map Range node scaled to a filter cutoff range, and connect that to the frequency input of the Low Pass Filter.
The result is a footstep that varies in pitch and brightness with each playback. The same recorded clip produces a noticeably different sound each time, without requiring multiple recordings. This is the same variation principle described in How to Design Footstep Sounds for Different Surfaces, implemented procedurally rather than through pre-made variations.
Exposing Parameters to Blueprint
A MetaSound becomes useful in a game when its parameters can be driven by gameplay state. This is done by promoting a node pin to a graph input, which creates an input parameter that Blueprint can set.
To promote a pin, right-click on it and select Promote to Graph Input. The pin becomes a named input node in the Interfaces panel. The name and type can be adjusted in the Details panel. For a footstep, useful inputs might include a float called Surface hardness that controls the filter cutoff, a float called Movement speed that controls the pitch range, and a float called Wear that adds a slight detuning over time.
Once the inputs exist, the MetaSound can be played from Blueprint and its parameters set at runtime. The pattern is to get the MetaSound component, call Set Float Parameter with the input name and value, then call Play. The value can come from anything the game tracks: the physical material the player is standing on, the character's velocity, the amount of time since the last footstep, or a stat that changes over the course of the game.
This is where MetaSounds becomes more than a sound effect container. The sound is no longer a fixed asset that plays when triggered. It is a system that produces a different result depending on the state of the game at the moment it is triggered.
Layering Procedural and Recorded Sources
A MetaSound graph is not limited to a single source. A typical procedural effect combines a recorded element with a synthesized one. For a footstep, a recorded impact provides the physical character, while a short synthesized noise burst provides a transient that can be shaped independently.
To layer sources, use a Mixer node with multiple inputs. Connect the recorded Wave Player to one input and a Noise node to another. Apply separate filters and envelopes to each before the mixer, so that the noise burst has a very short duration while the recorded impact has its natural decay. The mixer combines them into a single output.
This is the same layering logic that applies to weapon sounds and explosions, where a transient, a body and a tail each come from different sources. The difference here is that the layers can be generated at runtime and modulated by game state, rather than being pre-mixed into a single file. The layering approach itself is covered in How to Make Weapon Sound Effects for Games.
Using MetaSound Presets for Surface Variation
MetaSound Presets allow a single base graph to be reused with different parameter values. A footstep graph that exposes a set of inputs can have presets for grass, wood and metal, each with different filter settings, pitch ranges and source clips, all sharing the same graph topology.
The advantage is maintenance. If the graph logic needs to change, editing the base graph propagates the change to every preset that references it. Without presets, each surface would need its own graph, and every change would have to be applied separately to each one.
In practice, a surface-aware footstep system uses one base MetaSound graph and a preset for each material. The game selects the preset based on the surface the player is standing on, and the preset supplies the appropriate parameters to the shared graph. The surface detection logic in the game is separate from the audio system, but the two are connected through the preset selection.
When MetaSounds Is the Right Choice
MetaSounds is not a replacement for every sound in a project. It is a tool for specific problems, and using it for the wrong ones adds complexity without benefit.
It is the right choice when:
- The sound needs to change with game state. A footstep that varies with speed, a weapon that changes with upgrade level, a UI sound that responds to the current menu context.
- Repetition is a problem. Sounds that play frequently, like footsteps, hits or UI clicks, benefit from the procedural variation that MetaSounds provides without requiring a large library of recorded variations.
- The sound has no natural recording. Sci-fi effects, energy weapons, abstract UI sounds and other synthesized effects can be generated entirely within the graph, without needing any audio files.
- The sound needs to respond continuously rather than on a trigger. A car engine that changes pitch with RPM, a wind ambience that intensifies with weather, or a charge-up effect that builds over time.
It is the wrong choice when:
- The sound is a fixed asset. A coin sound that plays the same way every time, a menu click, a simple explosion. A Sound Cue playing a pre-recorded file is simpler and cheaper.
- The target platform is resource-constrained. On mobile and low-end hardware, the CPU cost of a complex MetaSound graph can outweigh the benefits. Sound Cue is cheaper for simple playback.
- The sound is a one-off. If a sound plays once or twice in the entire game, there is no benefit to building a procedural system for it.
Common Mistakes
- Treating MetaSounds as a fancy Sound Cue. If the graph only selects between pre-recorded clips and plays them without modification, a Sound Cue would do the same job with less overhead.
- Building complex graphs without profiling. MetaSounds run on the audio thread, and a graph that works smoothly in the editor can cause audio dropouts on the target hardware. Profile on the actual device.
- Forgetting to remove the OneShot interface on looping sounds. A looping ambience will stop after one playback if the OneShot interface is left active.
- Exposing too many parameters. A graph with twenty inputs is difficult to configure in Blueprint and difficult to debug. Expose only the parameters that actually vary during gameplay.
- Duplicating graphs instead of using presets. If the same graph logic appears in five separate MetaSounds, maintenance becomes difficult. Presets solve this.
What to Check Before Shipping
Profile the MetaSound on the target hardware before committing to it for frequently played sounds. The cost of a procedural footstep is higher than the cost of a pre-recorded one, and on mobile the difference matters more than on desktop.
Test the sound in context with the rest of the game audio. A procedural footstep that varies in pitch and filter cutoff sounds convincing in isolation, but it can become distracting if the variation range is too wide or if the filter sweep draws attention to itself. The variation should be subtle enough that the player does not consciously notice it.
Check the parameter values that Blueprint sends. A parameter that receives an out-of-range value can produce a sound that is unexpectedly quiet, distorted or silent. Clamping values at the graph input or on the Blueprint side prevents this.
Finally, consider whether the procedural system is actually necessary for the sound in question. A footstep with a small amount of pitch variation can be achieved with a Sound Cue and a Random node. The additional capability of MetaSounds is only worth the additional complexity when the sound genuinely needs to respond to multiple continuous parameters. If a simpler tool produces the same result, the simpler tool is the right choice.