We are doing a game mechanic that relies on FMOD Tempo beat callbacks and switching multiple parameters. It it similar to Guitar Hero.
We ran into a problem where we want to switch multiple parameters to some different values, but this change could happen at any point - although all changes happen at the same time. The issue we have now is if we queue to FMOD to change parameter values at an awkward time right before a beat happens, and in FMOD Studio we only apply these parameters with quantized condition (half note or something similar), then sometimes some parameters are delayed until the next allowed beat.
This creates a desync between what the game thinks was successfuly applied, but in reality it was not.
Is there any mechanism to handle this scenario?
We tried several workarounds, like having a callback parameter using command instruments, preemptively setting parameter and handling the incorrect state later or something else.
Hi,
It’s likely that all of the setParameter calls aren’t making it through the scheduling window Studio uses to check for timeline behavior like quantization during playback. I’d recommend trying a couple things:
Using Synchronous Update may also be worth trying, but it is a fairly drastic change to how the Studio system operates.
Otherwise, if none of the above options resolve the issue, can you please explain how your event and the parameter changing and quantization are set up so I can test it on my end?
Also, just to be sure, what version of the FMOD Engine and Studio are you using?
Just following up on this - were you able to resolve the issue with synchronizing parameter changes? If not:
- Did any of the suggestions I made in my previous reply make any difference?
- Can I get you to describe in detail how the parameter changing and quantization is set up?
- What versions of the FMOD Engine and Studio are you using?
Hey,
from what we tested, syncronous update would fix it, but as you said, it was quite a drastic change that affected the rest of the project.
In reality, the problem was the Studio internal update loop of 20ms. This is not synced with Unity, and parameters can be set early or late against the loop and the quantization condition. We managed to get around this by always waiting for beat 4 callback and inside that setting the parameters for the next bar.
Maybe it’s more of a design issue how we did it. Our feature is a multitrack song playback with user inputs at specific stages, and if not done correctly it triggers a fail sequence.
It’s currently stable to set the next bar type on beat 4, then go into fail if user enters wrong input or doesn’t enter it at all.