Workflow suggestions for advanced track transition logic

Hey all, I’m working on a game and currently have all my music (combat, ambient1, ambient2, etc) in a single event. I’ve been looking into some more complex logic for triggering ambient music and am not sure that the capabilities exist inside FMOD. My goal is to probabilistically fade into Ambient2 at the end of playing Ambient1. Ambient2 is more exciting than Ambient1, but shouldn’t be repeated very often. So I wanted to also keep track of the time elapsed since Ambient2 was last played so that if it was played in the last X minutes, it won’t be triggered again.

This is just one of the more complex things I’ve been thinking of implementing. Maybe I want Ambient2 to only end naturally (no crossfading to silence). I have a feeling my issues can be solved with a different workflow (aka not stuffing all my music into one event). I’m curious what sorts of things other people are doing. Do you put each track into a different event and handle triggering in the game itself? If so, how do you handle more nuanced transitions (you might want to crossfade different lanes at different speeds, etc). Or is there something else that you do?

Thanks!

This behavior wouldn’t be too hard to set up in an FMOD Studio event. The smooth fade-in and fade-out of music can be achieved using AHDSR modulators, and logic markers with probability and parameter trigger conditions can be used to make the transition occur randomly. If you used a parameter with velocity as a timer for how long it has been since Ambient2 was last triggered, you could use that parameter as the parameter trigger condition for the logic marker that triggers the Ambient2 instrument, and reset the parameter’s value by using a set parameter command instrument.

That being said, there is no one best way to implement music for a game. There are plenty of other ways you could get the same behavior. Different ways will suit different projects, so you’ll have to experiment to work out which works best for your game.

Thanks Joseph - I never thought about using velocity and had no idea set parameter commands existed - been looking for this for quite some time!

I wanted to create a “time_elapsed_since_x” parameter that the game doesn’t get to change, so I set it to read-only, but that seems to disable the parameter’s velocity. When I don’t set it to read-only, I can see a yellow circle track the value of the parameter (even though the parameter itself doesn’t seem to change value for some reason, maybe that value only changes when the game sets it?) - however when this gets disabled, I can no longer view the parameter’s value. Is that a bug?

This appears to be a bug that prevents parameter velocity from working when a parameter is set to read-only. Thank you for bringing this issue to our attention. I’ve added it to our bug tracker to be fixed in an upcoming version of FMOD Studio.

In the mean time, I recommend not using the read-only property for parameters with velocity.

This is normal and expected. It indicates that the final value of the parameter (the one that’s used in your game) differs from its set value (the value to which it was most recently set by code, command, or automation), a common occurrence when a parameter is subject to seek speed, velocity, or modulation.

I’m afraid I don’t understand what you mean. When what gets disabled?

Sorry, I meant when the read-only mode is activated. Thanks for the explanation - good to hear that I’m not going crazy, looking forward to the bugfix!