A jump sound in UE5 is not one asset played one way. It is a graph that fires on a trigger, chooses from a set of variations, applies a pitch offset, and routes through a filter chain — all at sample rate, per instance. A Sound Cue can approximate this, but it cannot respond to gameplay parameters while the sound is still playing, and it cannot generate variation beyond what was rendered beforehand.
MetaSounds is the production-ready replacement for complex audio logic in UE5.7+, and the jump is a small enough event to build the entire pattern in one graph. The MetaSounds guide for custom sound effects covers the broader authoring model; this article is about the specific graph, parameters, and trigger placement that make a jump sound work in a platformer.
MetaSounds vs Sound Cue for a Jump: The Difference Is the Graph, Not the Result
The jump sound is a good test case because it is simple enough that the difference between the two systems is not about synthesis complexity. It is about what happens after the sound is triggered.
A Sound Cue is a decision tree over pre-existing audio files. It picks which wave to play, randomizes pitch and volume, and maybe crossfades. Everything it can produce was rendered in a DAW beforehand. A MetaSound is a DSP graph that runs at audio rate, per playing instance. It can do everything a Sound Cue does, plus generate audio from oscillators and noise, filter it, modulate it, and accept parameters from gameplay while it is playing.
For a jump, the difference shows up in three places. A Sound Cue can randomize which of five recorded jump variations plays. A MetaSound can randomize which variation plays and apply a continuous pitch offset that is not available as a recorded variant. A Sound Cue can set a filter at authoring time. A MetaSound can expose that filter frequency as an input and change it at runtime from a Blueprint — for example, to make the jump sound thinner when the character is in a different state.
The row that matters for a platformer is the continuous parameter control. A jump that has to change character based on vertical speed, surface, or character state is a jump that benefits from a MetaSound graph, because the graph can read those values without retriggering the sound. The Unity vs Unreal audio tools comparison covers the engine-level difference between Sound Cue and MetaSounds in more detail.
The Jump Graph: Trigger → Random Get → Wave Player → Filter → Envelope
The minimal jump graph has five stages, and each stage solves a specific problem. The order is deliberate: the trigger starts the event, the random get chooses a variation, the wave player plays it, the filter shapes it, and the envelope closes it cleanly.
Stage 1: On Play Trigger. A MetaSound does not produce audio because the asset was assigned. The graph runs, but the amplitude stays at zero until a trigger reaches the envelope. The On Play trigger is the event that starts the jump. It should connect to the envelope's trigger input, and — depending on the graph — to the random get node if the graph is designed to select a new variation on every trigger. The most common silent-graph failure is a missing trigger connection: the graph previews without error, the wave player is correctly configured, and nothing is audible because the envelope never received a trigger.
Stage 2: Random Get from a Wave Array. The Random Get node takes an array of wave assets and returns one element each time it receives a trigger. For a jump, the array should hold four to six recorded variations — the same minimum that a Sound Cue random container would use, but inside a graph that can do more with the result. The array does not have to contain only recorded jumps: a MetaSound can mix recorded variations with procedurally generated tones, so a jump set can have three recorded takes and two synthesized variations without needing two separate systems.
Stage 3: Wave Player. The Wave Player node plays the selected wave asset. Its key settings for a jump are: loop off, because a jump is a one-shot; playback speed and pitch left at 1.0 by default, because the pitch offset comes from a separate random float stage, not from the playback rate (using playback rate for pitch variation also changes duration, which is a problem for a short jump); and start offset at 0.0 unless the recorded variation has leading silence that needs trimming.
Stage 4: Filter. The filter stage is where a MetaSound jump can do something a Sound Cue jump cannot: expose the filter frequency as a graph input and let gameplay change it. A jump that needs to sit in a mix with music and other effects benefits from a one-pole high-pass or band-pass around the jump's identity band. A typical starting point is a band-pass centred around 1–3 kHz, with a moderate Q, so the jump's attack sits in the region where the ear is most sensitive and where the music is often thinner. The frequency range guide for platformer jumps covers the band placement in more detail.
Stage 5: Envelope. The envelope closes the sound cleanly and prevents the click that a wave ending at non-zero amplitude produces. For a jump, the envelope should have a very short attack — 1–5 ms — so the onset is immediate but not discontinuous; a short hold that covers the body of the jump; and a decay that reaches zero before the wave ends, so the stop is silent. The envelope is also the node that the On Play trigger must reach. If the graph has a filter and a wave player but no envelope trigger, the graph will run silently.
Randomization: Two Nodes, Two Different Jobs
A MetaSound jump uses two kinds of randomization, and they solve different problems.
Random Get selects which wave asset plays. It is a discrete choice from an array, and it is the correct tool for variation between recorded takes. Each trigger produces one selection; the selection does not change while the sound is playing.
Random Float generates a continuous value that can be used for pitch, volume, or filter modulation. For a jump, the most common use is a pitch offset of roughly ±2 semitones, which is enough to break exact repetition without making the jump read as a different move. The value can be mapped through a Map Range node to a multiplier, or used directly if the downstream node accepts the range. The pitch variation threshold guide covers the identity threshold that sets the upper bound on this range.
The two nodes are often used together: Random Get chooses the take, Random Float applies a small pitch offset on top of it. That combination produces a jump that is recognisably the same event but never identical, which is the variation pattern that prevents repetition fatigue without requiring a larger sample library.
A third randomization pattern is available when the jump needs to vary over time rather than per trigger. A Trigger Repeat connected to a Random Float can generate a periodic modulation — useful for a sustained motion layer, not for the initial impulse. For a one-shot jump, the per-trigger randomization is the relevant pattern.
Exposing Jump Parameters to Blueprint
A MetaSound input is invisible to gameplay until it is promoted
to a graph input. Once promoted, it becomes a named parameter
that Blueprint or C++ can set on a playing Audio Component
using SetFloatParameter,
SetBoolParameter, or
SetTriggerParameter.
For a jump, the parameters worth exposing are the ones that change the sound's character in a way the game can decide: PitchOffset (a runtime pitch adjustment, in semitones or as a multiplier, applied in addition to the per-trigger random offset), FilterFrequency (the centre or cutoff of the jump's filter, useful for making the jump thinner in a noisy scene or fuller in a quiet one), VolumeMultiplier (a runtime gain, separate from the per-trigger random volume), and PlayJump (the trigger that starts the graph, separate from the On Play trigger if the graph is designed to be retriggerable).
The jump function in the character Blueprint becomes a short sequence: set the parameters that differ from the default, then fire the trigger. The graph does the rest at sample rate, without a Blueprint tick.
// In the character's jump function
JumpAudio->SetFloatParameter("FilterFrequency", 1500.0f);
JumpAudio->SetFloatParameter("PitchOffset", 0.0f);
JumpAudio->SetTriggerParameter("PlayJump");The values can come from a curve, a data table, or a gameplay tag lookup, depending on how the project is organized. The important part is that the jump sound is not a fixed asset; it is a graph that receives the values the game already knows.
Jump Cues: Where the Trigger Lives
The trigger that starts the jump graph is not the same as the input event. A jump input fires on the frame the player presses the button. The jump executes on the frame the character leaves the ground, which may be later if the jump is buffered or if coyote time is in use.
The trigger should be placed on the execution frame, not the input frame. A jump that is buffered for 100 ms and plays its sound on the input frame will sound early relative to the character's motion. A jump that plays on the execution frame will sound aligned with the visual departure. The Unity 2D jump setup guide covers the same execution-versus-input distinction in a different engine.
In a Blueprint character, the execution frame is usually the
frame where the velocity is set and the isGrounded
flag is cleared. The Audio Component call should be placed
after those two operations, not before. The same rule applies
whether the jump is a single, double, or wall jump: the trigger
belongs to the moment the movement is committed, not the moment
the input is recorded.
If the game uses an Animation Notify for the jump, the notify can fire the trigger, but the notify's timing has to match the movement's commitment frame. An Animation Notify that fires a few frames after the velocity change will produce a sound that feels late even if the clip is perfect. The jump and landing guide covers the movement system that the cue has to align with.
Concurrency and Voice Management for a High-Frequency Jump
A platformer jump fires more often than almost any other sound. A MetaSound graph that creates a new instance on every trigger can exhaust the audio voice pool if the trigger is not rate-limited.
The concurrency system in UE5 is the first layer of protection. A Sound Concurrency asset assigned to the jump's Sound Class can limit the number of simultaneous instances and define what happens when the limit is reached — usually “stop oldest” or “stop quietest.” A limit of 3–4 simultaneous jump instances is usually enough for a platformer, because a player rarely presses jump more than a few times per second, and a higher limit mostly serves to allow overlaps that the ear cannot separate anyway.
The second layer is the graph itself. A MetaSound graph that runs per instance should not contain nodes that are expensive relative to the sound's duration. A jump that lasts 150 ms does not need a granular synthesizer or a complex modulation matrix; a wave player, a filter, and an envelope are sufficient, and they keep the per-instance cost low enough that a small concurrency limit is not a performance problem.
The third layer is the trigger rate. If the jump trigger is tied to the input rather than the execution, a player who taps the button repeatedly can fire the graph more often than the character actually jumps. The concurrency limit catches the excess, but the better fix is to trigger on execution, so the graph fires once per committed jump. The sound prioritization and voice limiting guide covers the broader concurrency architecture.
What the MetaSound Jump Cannot Fix
A MetaSound graph can generate variation, respond to gameplay parameters, and run at sample rate. It cannot fix a jump that is triggered on the wrong frame, a jump whose variation pool is too small, or a jump that is masked by the music because its identity band was never chosen.
The graph is the system that applies the decisions; it is not the decisions themselves. A jump that uses a MetaSound with four recorded variations, a ±2 semitone pitch offset, and a band-pass filter around 1.5 kHz is a jump that has made the right decisions and implemented them in a system that can change them without re-authoring the asset. A jump that uses the same graph with one variation, no pitch offset, and a filter that was never adjusted is a graph that is doing nothing the Sound Cue could not have done.
The jump sound in UE5 is not a file. It is a graph, a set of parameters, and a trigger placement. The graph is the part that is visible in the editor. The parameters and the trigger placement are the parts that determine whether the jump reads in the game. The prototype versus polish guide covers the point where the graph is functional and the work shifts from “does it fire” to “does it read.”