Hi all,
I’ve been managing all of the music tracks of a game as nested events inside one main FMOD event, as I’d like to dynamically transition between these different tracks. Now, since each of these nested events already have some logic and transitions between different sections of different tempo, I can’t have the tempo on the main event be the same as the tempo of the nested events since they dynamically change.
So, is there a way for the transitions that happen on the main event to be quantized to the tempo of the nested events? If not, does anyone know a different way of implementing this that would give me the same result?
Thanks in advance!
No, you can’t, the quantization options inside the nested events always follow the rules of the parent event, which is unfortunate… Check this post.
I’m not sure you’ll be able to setup things like you want. But let me know, I’m interested in that.
I found a veeeery hacky way to make this work, but it seems so hacky I’d be afraid to actually use it without more tests… but since you’re interested:
This only works with more recent versions of FMOD (02.01 onwards) since it needs combined transition conditions and extended functionalities of the command instrument for it to work.
So, you need two parameters to control the transitions: the one that will be hooked in code (called “Transition” on the pics) and another that will control the actual quantization (called “CanTransition” on the pics). The first one would be your standard parameter that we’re already used to. The second one would be controlled via command instruments on the nested event.
We need combined conditions because here’s what we can do: we can set the conditions of the transition to be “Transition” = 1 AND “CanTransition” = 1 (see pic 1), so even when the actual transition is called at the parent event level, it will only transition when the “CanTransition” parameter is also set to 1. And we’re controlling when that happens inside FMOD via Command Instruments.
So let’s say that you want the transition to happen on the beginning of every bar of the nested event. You’d put one command instrument that sets the parameter “CanTransition” to 1 at the beginning of every bar (see pic 2 - this is the timeline of the nested event). So even when the “Transition” parameter is set to 1 via code, which usually would make the transition to happen immediately, FMOD will wait for the “CanTransition” parameter to also be set to 1 before transitioning. Since we control when that happen in the timeline, we can set it to transition on time! Now usually the “CanTransition” parameter would keep the value of 1 after going through the first command instrument, so to solve that we make its velocity to be negative, so it will jump to 1 for a time and then go back to 0 until we set it to 1 again with another command instrument.
But, as I said, this is veeeery hacky. One problem is that the command instrument doesn’t seem to set the parameter change at the exact time it is triggered, so you need to offset it (placing the command instruments before you want to actually trigger the change, trying and testing until you find the correct place - very time consuming). Another problem is that the value change might keep the parameter at 1 for an amount of time, and even if it’s a small amount of time, if the “Transition” parameter happens to get set to 1 while the “CanTransition” parameter is also at 1 but out of the quantized time, the transition won’t happen on the beat. And last but not least, this workflow just doesn’t seem sustainable to me on large projects, and I have no idea if triggering command instruments every so often can cause any problems to performance.
So, it’s doable in a way, but this is definitely not a solution. I really hope the FMOD team make this possible in the near future, and I’m sure they will at some point - if anything, maybe this “hack” give them some light as to how to achieve this? 
)
1 Like
