How about using timeline callbacks for rhythm driven game?

I’m making rhythm based game and I’m wondering if the timeline callbacks are good approach. I’m aware that probably timeline markers and their quantization options are good start for calling out some events and stuff, but what about tempo slow down for example? Is it possible to seamlessly transfer between tempos within one song without losing the groove? Is it possible to do with Snapshots for example?


There are two ways in which the tempo of an event can change in real time.

It is possible to place multiple tempo markers in an event, each with its own time signature and BPM. If there are multiple tempo markers in an event, each tempo marker sets the BPM and time signature for the region of the timeline between that marker and the next tempo marker to its right. This means that if the timeline playback position moves from one region of the timeline to another, the event automatically starts using the BPM and time signature of the new section for the purposes of quantization and other time signature- and BPM-dependent behavior.

The BPM and time signature specified by a tempo marker is the base rate, assuming the event is not subject to any time stretching pitch adjustment. If the event’s pitch adjustment (as defined by the pitch dial in the event macros and the pitch adjustment applied by any group bus into which the event is routed) is positive or negative, the event’s timeline playback position will move faster or slower, resulting in a faster or slower BPM, without changing the timeline positions of any bar or beat markers.

There are a number of ways in which you can take advantage of these features. To give some simple examples:

  • If you want a piece of music whose tempo and time signature varies over its length to always transition on-beat, you can create the music as a synchronous instrument and place a tempo marker on the event’s timeline at each position where the tempo changes.
  • If you want to lower the music’s pitch and speed for a few moments whenever the player makes a mistake, while still ensuring stingers are quantized to the beat, you can automate the event’s pitch macro control on a parameter with velocity, such that the event’s pitch and speed changes when set and then naturally resets to its normal value after a moment.
  • If you want a piece of music to play at two different speeds without pitch adjustment, you can record the piece of music at two different speeds, place them both on different regions of the same event’s timeline as synchronous instruments, place a tempo marker at the start of each instrument that accurately represents that instrument’s tempo, and then use quantized magnet regions or transition regions to jump from any position in the fast version to the equivalent position in the slow version, and vice versa.

Does any of that sound like what you want?

1 Like

Hey Joseph,
Kudos for this voluminous explanation - that’s exactly what I wanted to know except, I don’t really get how can I condition Macro Pitch change, as there is no posibility for adding parameter conditions.

Didn’t know about the Magnet Regions, absolutely fantastic concept!

You don’t need a parameter condition. Just right-click on the pitch property, select “Add Automation,” then add an automation curve for the parameter of your choice. Automation is a way of making a property’s value change depending on the value of the parameter on which that property is automated, and you can read about it in our documentation.

Yes, I know about the automation and that I can do it with almost anything in Fmod, but what if I would like to change the Event’s Pitch - to do a slow-down for example, and do it only when some conditions are met?
Take care Joseph

Just an idea, maybe use a command instrument that starts or stops a snapshot and add the trigger conditions in there. Or use the set parameter command type if it’s only about the single event and automate the pitch with that parameter.

Hello alexzzen!
I’m in the prototyping phase, so I’m trying out different approaches, but what I try to achieve is to have the same functionality/parameters set to use within single events. I would use snapshot approach as I mentioned earlier, but not sure it won’t destroy my timing inside the event.

There’s a couple of different ways you could attempt this, but my first choice would be to make a snapshot that’s active only when the conditions are met, have that snapshot set a global parameter to a specific value, and use that parameter to automate your event’s pitch macro. You’ll also want to add an AHDSR modulator on the snapshot’s intensity, so that the pitch changes gradually instead of instantly when the snapshot is started and stopped.

1 Like

Hey Joseph!
Thanks for the help. That clears out so much and it’s superbly helpful!
One more little thing that’s bothering me right now, could you tell me if there is smarter way than using timeline markers and using callbacks inside Unreal Editor for spawning some events/other stuff? Is it a reliable way to deal with rhythm based stuff? Like let’s say for example adding two markers per Kick-hit (on start and on the end of the sound) to check if the player has done specific action during that interval?
Anyway. Kudos to you my friend, that already helps me big time

I don’t think there’s another way than using callbacks to do this kind of things! Why not directly using beat callbacks instead of timeline markers callbacks? You can easily filter the beat subdivision you want to callback (edit: false). Haven’t checked if it was possible to mesure the timing offset of a player action in regard to this callback in UE, though.

Yeah, I’d use preferrably Timeline Beat callbacks but it’s limiting the beats to quarter notes and not taking syncopation into account. So I can probably merge those two options with Timeline markers to get the desired effect.
Thank you for the answer bro.

That’s true, I mistakenly said we could callback a beat subdivision. However you could double up the tempo marker to have 2x more beat callbacks (or 4x).

Neat trick :slight_smile:

And by the way, have you thought of loading your time-critical banks with the option loadSampleData? It may be a good thing for a rhythm game.

Great advice. I’ll look into it for sure. Don’t want to piss anybody on false off-beats. Thank you!

Hey Joseph,
one more quick thing, how can I have Snapshot setting a global parameter? I have some global parameters made, but can’t locate them in “parameters in scope” in mixer view.while snapshot is activated. Any ideas?

I don’t see neither how a snapshot could trigger a parameter. We’ll wait for joseph answer.
However, here’s another idea: route your event to a particular mixer track (for the pitch effect to not by applied on SFX, for instance) and create a snapshot triggering a pitch effect on that mixer track, while using AHDSR on the snapshot, and add the trigger behavior conditions you want where you call that snapshot in your event.
However, I know the pitch effect doesn’t behaves the same as the instrument/event pitch modulator (why is it designed so, by the way?)

Actually I came up with same thing few moments ago, routed events that I want to pitch modulate to a new Mixer Group, than created a snapshot which when activated modulates this Mixer’s Group Pitch. Then created a Parameter and dropped the Snapshot on Parameter’s Event Track in my event.
Everything works as expected. The pitch on Mixer Group works same way as the one on Event’s Macro for what I’ve seen. I will know after some further testing if it gives me some trouble an messes my tempo for example.
Kudos to you Alcibiade

1 Like

Oh, you’re right, mixer groups benefit from the same pitch modulator than events/instruments, haven’t noticed that before!

Whoops, that feature hasn’t been released yet. My mistake.

Alcibiade’s solution of adjusting the pitch of a bus is a more possible solution.

The pitch shifter effect differs from instrument-, event-, and bus-level pitch adjustment because it allows time-invariant pitch shifting. Time-invariant pitch shifting allows you to change the pitch of a sound without affecting its speed, but is much more computationally expensive.