koobas.hobune.stream
Calculating BPM (beats per minute) using InvokeRepeating() - Issue
Hi,
I am making a music based game/app and need to have a BPM system that fires off events in time. Obviously Unity works on Update() ticks and I need to find a way to convert these ticks to a system that I can use musically via BPM and 'Beats Per Bar' (the divisions that drum notes can play on between the pulse beats).
What i've tried already is having a method SetTempo( int bpm, int ticksPerBeat ) and using this to work out how often I should fire my own Update method called UpdateRepeating(), via the InvokeRepeating() method which basically just calls my method over and over again every x number of seconds. Using this, i'm able to write some procedural drum loops and they play out as i expect, but I'm getting slowdown by simply moving my mouse around the screen at any kind of speed or by scrolling over my Mac's dock. Is there another way I should be doing this that won't cause slowdown?
Should I be using a Timespan to give an accurate measurement of ticksPerMinute to somehow work out when my UpdateRepeating() should fire?
Thanks
Mat
If you need something that is very regular, I would probably create a coroutine which yields WaitForFixedUpdate() and keeps track of time to call the your UpdateRepeating(). You could use WaitForSeconds, but in my experience, it is less regular than WaitForFixedUpdate.
//C# IEumerator PeriodicUpdater() { float waitTime = 10; //10 seconds between updates
float curTime = Time.time; while (true) { if (Time.time >= curTime + waitTime) { UpdateRepeating(); curTime += waitTime; } yield return new WaitForFixedUpdate(); } }
For anyone else trying to have a stable bpm in a music game, InvokeRepeating is what I would advise. Tested many different methods, and asked for more experienced users opinions, all point to InvokeRepeating. Not sure about how that would fare on iPhone, though. Just posted a question on the subject.
Just for the record: Waiting for FixedUpdate makes no sense. All coroutines, Invokerepeating "tasks" and even FixedUpdate they are handled all "per frame". FixedUpdate is a time-fixed update function, not a fix-time update. FixedUpdate isn't called at fix timesteps. It is called just before Update "if necessary". If your framerate is higher than your configured fixtimestep FixedUpdate is not called every frame to keep its CallsPerSec. If your framerate is lower than your fixtimestep FixedUpdate is called several times at once.
No matter what you do, FixedUpdate calls are always based on your framerate. Unity uses a single thread approach for the scripting environment.
I'm not sure how InvokeRepeating will handle framerate fluctuations but your approach will definately work as expected but a yield return null will do since it will ensure your timecheck will happen as fast and as often as possible ;)
+1
I know i am late for the party but for future references ill post my findings.
I dont know if unity released this at a later date but the Audio system features a AudioSettings.dspTime. Documentation description:
This is a value specified in seconds and based on the actual number of samples the audio system processes and is therefore much more precise than the time obtained
The documentation has a nice example how to make a steady beat at 140 Bpm. http://docs.unity3d.com/ScriptReference/AudioSource.PlayScheduled.html
