Step Sequencer - Stable Timing

[Innerworld]

I’m trying to figure out a way to get stable timing in UE4… To make a drum step sequencer mainly, like the classics from the 80’s…

But using the event tick isn’t working, as that seems bound to the FrameRate. Looking around the web I see people mention Fmod, but can’t figure out how to get a beat/tempo output from it.
Since there’s so much great work happening with the new audio subsystem, I was curious to hear if and how you guys are triggering the synths without a stable clock source…

Is there a work around? I even thought of using an LFO output from the synth, but I don’t think there’s an actual output for just the LFO freq… I read also about making an external simple DLL that could just get the computer clock and pass it thru to UE4 / blueprints, but I’m not a programmer… I need blueprints!

Curious to hear about timing in general in UE4, how do developers get a stable tick tock clock?

[ArthurBarthur]

In BPs, add Timelines(triggering smaller timelines), their timer is independent from gamethread. There is also the nodes Set Timer By Event/Function.

[Innerworld]

Thx a lot for the hints! I’ve tried the timelines thing already, I made event tracks with ticks on bar, beat and 16th…at least I think that is what you meant? Like this:

​

​

I’ve previously just tried the below setup, which has the same type of fluctuation when previewing in viewport, looking around will inc/derease the FPS and the playback along with it,
when I set a fixed FPS in the engine’s settings, it’s more stable (when I set below 60FPS), but still can and will get affected by the game’s FPS overall…

​

Btw, this is a basic actor BP, in the world with a few lights to keep the position visible, but as you can see from screenshots 1 and 2, that’s a super basic setup, there’s no overhead there…

[Konflict]

@Innerworld You can also try to experiment with timers. A fairly high resolution (eg 0.001) setting will provide you 1000 events per seconds which you can use to trigger the audio when required. This is not extremely accurate but likely won’t be bound to the fps.

There is also ways to use threads in blueprints which you can perhaps exploit for this reason. At least 2 marketplace plugins exists to implement threading, that way you can unbound the timing from the game thread perhaps. No promises tho!

[Innerworld]

Thx Konflict… I’ll see how these timers can work… Do you have an example by any chance?
But from what I’ve noticed, all ‘seconds’ we can get in UE are based on frames, not on the internal computer’s clocks… This would be a nice feature to add, a ‘direct / realtime’ clock.
As for the threads, thanks, I’ll investigate those plugins, seems great for a programmer, I’m sure if you know how to write in C, it’s ‘easy’

[Konflict]

@Innerworld

have an example

Well it’s extremely simple, you just drop a timer node and it will tick on the choosen period that’s it.

Nothing spectacular or fancy here. You can choose any arbitrary time scale, for demo purposes i set it to be .001 that is 1msec per tick. You can go lesser resolution that still acceptable. Timers are not extremely accurate but they can serve their purposes fairly good.

In order to make sure the tick is accurate, you can connect and raise an integer here, that you will print out on every tick or 1 seconds, so you can measure the accuracy. It is fairly good might as well be good enough for the timings.

@Innerworld

all ‘seconds’ we can get in UE are based on frames, not on the internal computer’s clocks…
This would be a nice feature to add, a ‘direct / realtime’ clock.

I think you will go a little inbetween here with the timers, as they are in fact running on a lower layer of the framework, providing higher accuracy. You can get better accuracy from a stronger bounds to the cpu executions (eg a loop with a sleep() ) perhaps, but that is not an option for general purposes here.

@Innerworld

As for the threads, thanks, I’ll investigate those plugins, seems great for a programmer, I’m sure if you know how to write in C, it’s ‘easy’

Nah they run in blueprints, you don’t have to worry about coding that much. Code however doesn’t suffer from the VM’s inefficiency - but in a cooked game you can have nativized blueprints as well and they will perform way better.

[dan.reynolds]

Unless you’re running the Blueprint VM on a different thread, you will still be bound by the game thread tick.

However, Event Timers over long periods end up being more accurate than Delay loops because they do not require a Game Thread bound execution to start the next wait meaning your timer execution will always be ready to go on the next game thread tick and will already start up its next timer wait period.

However, on slow game threads, you will still experience time phasing, particularly on tight timers that are out of sync with the Game Thread.

Which brings us to a final optimization, having a musical timing that is synchronized with your game thread is probably your best bet. If you’re shooting for 60 or 90hz as your spec frame rate, then ensuring that your musical timing is compatible with those sync rates is probably the best thing you can do for your implementation.

[Innerworld]

Thanks Konflikt for the example! It did help me understand the ‘trigger’ mechanism of the TimerByEvent! Now I’m experimenting along those lines… It seems more stable indeed!

I also noticed something interesting, when I use a fixed FPS of 60 in the general.settings, and play (in window or PIE), looking at the FPS counter, when I look at the drum machines (geometry), it’s sticking at 60 and the tempo is solid, but as soon as I look away, in the ‘void’ (ie no models/no sky), the FPS jumps to 100+ and the tempo slows down (a lot), then I look back at the models, the FPS goes back to 60 and the tempo speeds up as if it’s ‘catching’ up the missed beats… On the other hand, setting the FPS in the settings to smoothed frames, 90-120-60 (60 min, 120 max, 90 smoothed), the tempo is much more solid and looking around / changing geometry count has no impact at all! … Just wonder if you guys know why, one would expect that when it’s at 60, it should stay there, and not change when you have 0 polygons on screen

I also noticed that adding some delay before everything stabilizes things… Here’s my -very early- prototype:

Anyway, thanks Dan also! Must say that the work you guys have done for UE is fantastic and I can’t wait to dig into the synth side of things (I own quite a bunch of analog synths / making electronic music for nearly 30 years) and was so surprised and happy to see these audio features integrated into a 3d engine - part of what motivates me to learn UE

Thx for the info, though I’m afraid you are talking a little above my -current- brain-grade, lingo-wise, but I understand the general lines you are describing, I have much to learn still!
It sure is a lot of fun! … when I saw these little lites blinking as they should on the beat… Now I just have to learn about programming a multi-sound step sequencer:

Lovin’ UE4!

Cheers,
Nick.

[dan.reynolds]

Wow, Nick! Those Roland drum machines look awesome! Really nice work!

[Innerworld]

Thanks Dan! It’s of course mostly thanks to the HQ fidelity of UE4
Modelling / visual stuff isn’t hard anymore for me, the programming / logic stuff is the tricky part atm…

[Minus_Kelvin (Aaron McLeran)]

Great stuff! Everything everybody said here is correct.

We’d like to add sample-accurate timing via BP in the future with some sort of new component which allows you to schedule events to a specific sample-accurate clock at the cost of a bit of overall latency. This isn’t done yet, but is definitely something on our roadmap to solve.

However, using the methods described here, unless your framerate is super spikey/jittery, we’ve found you can get pretty far even if using the game thread as a sequencer/timer. The biggest practical issue with game-thread timing imo, is issues like application tabbing (tabbing in and out of app), and in windowed mode, when you drag a window it pauses the game thread. Any procedural audio dependent on that is going to get jacked. But normal “gameplay” is fine.

[Innerworld]

Hi Minus,

That sounds great! (a sample accurate timing - via BP), looking forward to that! I’m sure there are applications that could benefit from an ‘RTC’-like timing…

And yep, as you point out, my main worry about timing came from the fact that the BP editor window pauses the thread often, which is just an issue when programming, as soon as I simulate without the BP editor window open, it’s sticking at 120FPS… even when I use the mouse for testing, then it lowers to 60 of course, as it’s syncs to the screen refresh rate.

But now I know this, plus, the use of timers works fine for now, even having 2 machines ‘in sync’ for now without a real ‘sync’ function, it stays in sync just by having 2 BP’s in the world with the same timers setup, it is amazing! … Lovin’ UE4

I was also a little concerned with the audio ‘headroom’ of the UE mix, specially with the TR’ sounds, they are very fat, I did notice a bit of ‘flattening’ of the Bassdrum when the closed hats are on for example, but for now I’m just using 2d-sound triggers, which are UI based, so perhaps it’s better to make a real mix and use 3d sound? What do you guys think about audio mixing ‘properly done’?

Another question, which is perhaps more VR-related, how would you go about controlling the potentiometers? I’m thinking of using the motion controller’s relative rotation, with some sort of line trace to ‘lock in’ onto the potmeter while the trigger is pressed, so that you don’t have to be too precise… Just curious to hear your thoughts on knobs/potmeters. I guess LeapMotion would be perfect for this, now we just need haptic feedback…

Anyway, progress is being made! I sorted out the sequencer parts and this is already very promising.
I’m sure a programmer would make this in a much more elegant fashion, but for now I have a beautiful looking BP

[dan.reynolds]

This is really awesome! Have you tried messing with the Synthesizer at all? I’ve had success building some 808 sounds with it previously. Would probably stress your perf more, but you could literally map synth parameters and allow your users real-time tweaking of the sound.

[Innerworld]

Thx Dan, yeah, I’ve played around with the Synth at the beginning of this ‘adventure’, but put it aside when building the sequencer… Wanted to make sure that it was stable at sequencing samples first… I will definitely get back to it, since I am hoping to emulate the synthesis too, or a mix/match … btw, I believe that the synths are also ‘wavetables’, right? Could I use a sample as an OSC?

I’ve started playing around with controlling the potmeters (level, attack, etc)… That’s a lot of fun too, but have to finetune the way the control is done with the motion controllers, for now I’m using a short linetrace from the index finger that detects the potmeters by tag and uses the relative rotation (yaw) of the motion controllers… I think I need to ‘lock’ them with a trigger action…

I will also checkout the signal paths, I will better read the tutorial you made about the synths, submixes etc… and the effects, can’t wait to test all this!

[Minus_Kelvin (Aaron McLeran)]

Yes, wavetable synthesis is a synth technique.

Check out SynthSamplePlayer as an example of something I did to sort of go through the parts you’d need to load a USoundWave as a wavetable and resynthesize it.

Here’s a BP I made today that randomly scrubs through a file backwards and forwards and randomized scrub points with randomized scrub widths… sounds really cool with music and dialogue.

[Innerworld]

Woah, thanks Minus! That looks cool… I’ll recreate the BP and have a listen!
I’ll definitely test with the SynthSamplePlayer, looks like it could be just what I need to replace the sound2d I’ve been using.

I can imagine that a random-scrub-time could be a fun effect! Specially for spooky/scifi fx…Does the -3.0 in the ‘in pitch’ range means it plays parts of audio in reverse too?

[DavidBoura]

Are you still on this? I have a similar project so yours is super interesting to follow ^^