I’m having a problem where some transitions and loops within a specific event work fine when the event is played in isolation, but fail to trigger on time when they are within nested events. The audio starts after some fractions of a second, still in sync.
I don’t know what is causing this. It only happens at a certain point, but with all audio regions that happen to lie at that specific point.
The event in isolation works fine:
…but nested within another, it fails:
All files that are located at the “Combat A” position fail, whether they come from the transition point or the loop region. The audio starts some milliseconds later, whereas the tail of the transition still plays. The rest of the transitions work fine.
I’m completely at a loss with this one. What’s happening?
Given the complexity of your event, it’s difficult for me to diagnose the issue from screenshots alone. If possible, can I get you to upload your project (or a stripped down version of it) to your FMOD user profile for me to take a look on my end, and provide a series of steps to reproduce the issue? Note that you’ll need to register a project with us in order to upload.
OK, will do. There’s an existing project created by the company. I’ve already sent an e-mail to the sales team for the existing project to be linked to my profile.
I’ve posted a striped down version of the project, removing most of its assets. The problematic event is M_Mission_1 when nested, specifically, the transitions that land in the Combat A loop region at the beginning. The event, when open in isolation, looks fine. To reproduce the problem, open pri_musicMain in the GameLogic folder. Set parameters mission_No to M_01 and enemyOn to true, and hit play. If you can reproduce the problem, after the first bars of music, there will be an incomplete transition.
I should add that I’m still on 2.02.15, which is the version used when we integrated FMOD into Unity. And that this stripped down version usually crashes FMOD. I’ve only removed some linked assets to save space, as well as the .cache folder, which weighted 1.5 GB
Thank you for your time.
Thanks for uploading your project.
The issue appears to be that the single instruments at the start of the “Combat A” region in the “pri_M_Mission” event are quantized to 1 bar. That particular timeline region is marked as 150bpm 3/4. However, because this event is being referenced and played by “pri_musicMain”, the quantization appears to be operating based on the parent event’s tempo - since there’s no timeline in “pri_musicMain”, the event is defaulting to 120bpm 4/4, and your instruments in “pri_M_Mission” are quantizing to the conclusion of the 120bpm 4/4 bar instead of the 150bpm 3/4 bar.
This behavior appears to be a bug, and I’ve passed it along to the development team for further investigation. For the moment, removing quantization from the trigger behavior of the instruments in the “Combat A” is probably the simplest workaround, but depending on what else transitions to that region, you may need to rework transition timings.
Thank you for your reply! I’ve created a Timeline sheet and placed a 150 tempo mark there. No other events seem to be affected by this so, for me, this workaround fixes it.
Should I be worried about any side effects?
There shouldn’t be any side effects unless there are more instruments in the referenced events that have quantization enabled - quantized transitions don’t appear to have the same bug. If you do run into any side effects though, feel free to let me know.