I’m working on a game where I have different loops that either well, loop, or hop between each other. Each section of music may loop on itself, or it may hop to another section of music, that may loop or hop to another one or back to the first one, etc. As you pass certain checkpoints, a new track is added to each loop (these checkpoints are parameters). I’d like to make it so that after you pass a checkpoint, the first time you hear a section of music, you always hear the new track that is added. If the section of music loops, said newly-added track has a probability of possible being heard, and possibly not.
Is there a way of doing this within FMOD studio itself, without having to add another parameter that would need to be integrated in Unity for the first time you pass a checkpoint? I tried nesting a multi instrument with the track and silence into a multi instrument that has the track and only plays once, but the timing got messed up- it needs to stay synced to the music. Maybe something with command instruments?
You want a change in your game’s state (whether the player has passed the checkpoint) to alter the behavior of the music event. You must therefore communicate this change in the game’s state to the music event somehow. There are exactly two ways to communicate a change in a game’s state to a playing event: Parameters and cues. You will need to use at least one of them.
Of these two, cues are more suitable for impulses (“something has happened and you should do something about it, but you don’t need to remember it afterwards”) and parameters are more suitable for permanent changes (“the player has passed the checkpoint, and you should remember that”). As such, parameters are the tool appropriate for your case.
As you have discovered, you can’t just rely on a time delay, because there’s no guarantee that the game’s state will change with the timing you specify. Your game has to send a message to the event, and parameters are the only appropriate of doing that.
Hi! Thanks so much for your help. I’m sorry if I wasn’t clear, but I already have a parameter in fmod that’s also already implemented in Unity for passing the checkpoints- that part of the system already works! I currently have it so that once you pass the checkpoint, the new track always plays. I also can change the probability so that it’ll play X% of the time, but that means there’s a chance it won’t play the first time you pass the checkpoint.
What I’d like to do, is have the new track play for sure the first time you hear the music, and if the music loops, have it be a probability that it might play, and it might not, for more variation. All of this info is internal to fmod from what I can tell- whether the track has already played or not.
@joseph Just wanted to check in on this again, I realized I didn’t tag you before so I’m not sure if you got the notification I replied. Thanks so much!
There is technically no way to do this - but you can come almost indistinguishably close to it.
Replace each music track instrument with a multi instrument.
Set each of the new multi instruments’ playlist selection modes to “sequential - play scope.”
Make the first entry in the multi instrument’s playlist the instrument that the multi instrument is replacing.
Make the second entry in the multi instrument’s playlist another multi instrument, which I’ll henceforth refer to as “the nested multi instrument.”
Set the nested multi instrument’s playlist selection mode to “random.”
Populate the nested multi instrument’s playlist with two instruments: One copy of the music instrument that the parent multi instrument replaced (i.e.: a copy of the instrument you added to the parent multi instrument back in step 3), and one silence instrument.
Set the play percentages of the two instruments in the nested multi instrument’s playlist to whatever you need them to be.
This configuration will mean that the first time the parent instrument is triggered, it will definitely play the music track; but the second time, it will have whatever percentage chance of playing the track you specified in step 7.
Of course, this does mean that the parent instrument is guaranteed to play the track every second time it is triggered - but you can dilute that by copying and pasting the second entry in the parent multi instrument’s playlist multiple times; doing so will ensure that the parent multi instrument is only guaranteed to play the associated track every n times it’s triggered, where n is the number of entries in its playlist.
If you’re planning to do this for multiple different instruments, I recommend making the number of entries in each parent multi instrument’s playlist a different prime number, to reduce the chance of entries predictably playing at the same time with a specific frequency.
Don’t worry, this forum is integrated with our support ticketing system, so we automatically get notified any time anyone posts in a thread to which we have previously responded.
When testing, I realized there’s another issue- sometimes, a section has two different endings- one that just loops, and one that leads into another key and thus another section. In the key change case, I currently have a transition with a probability a couple of bars before the end of the section that would otherwise loop, in the middle of the music, that jumps to the key change version of the ending that’s farther along the timeline (and then jumps to another section).
So going back to these tracks that, after the first time they’re triggered, sometimes play and sometimes don’t- is there a way to make sure that if said track is playing, it will also play when jumping to a key change version, and the same if it’s not playing?
I’m thinking I might need to go about key change endings in an entirely different way to make these two systems function together, but I’m having a hard time figuring out how to do so! Thanks so much for your help!
There’s no way to do it in combination with the method of using multi instruments to randomize whether specific stems play that I described in my earlier post. Multi instruments are simply not able to talk to each other in the way that would be required for different multi instruments to share the same state.
To achieve the behavior you want, you’ll need to use parameter trigger conditions instead:
Remove the multi instruments, and replace them with the instruments they previously replaced.
Create one parameter for each stem (counting the original version and the key-changed version as the same stem). It’s probably best to name these parameters after the stems to which they relate, to set their ranges to 0-1, and to set their initial values to 0.
Add a parameter condition to each instrument using the parameter you created for its stem, such that the instrument is triggered only when the parameter’s value is between 0 and x, where x is the probability that you want the instrument to trigger on the second and subsequent times that the instrument is triggered. For example, if you want the stem to only play 40% of the times that it’s triggered after the first, you should set the upper end of the parameter trigger condition’s range to 0.4.
Add a command instrument to your timeline at each point where you want a stem’s random chance of playing to be rerolled. Set the command instrument to “set parameter” mode, set its target to the parameter associated with the stem, and set its value to 0.5.
Right-click on the command instrument’s value and select “Add Modulation > Random” from the context menu to add a random modulator to the value property.
Set the random modulator’s value to 1.00.
This will ensure that the parameter’s value will be re-randomized each time the timeline playback position triggers the command instrument. (Setting the command instrument’s value to 0.5 and the random modulator to 1 ensures that the command instrument sets the parameter to a random value between 0 and 1.) More importantly, this method ensures that the parameter’s value won’t be re-randomized if the timeline playback position doesn’t trigger the command instrument, such as when the timeline playback position jumps to the different-key section of your timeline. This will allow you to ensure consistency when jumping the timeline playback position from one key to another.
That being said, there is one significant disadvantage to this method: Because it is affected by both update delay and scheduling delay, up to 80 ms may elapse between a command instrument being triggered and the associated stem’s instrument being affected. For this reason, you should try to position the command instruments somewhere where the stems associated with their associated parameters will never be playing; or, failing that, at points where their starting or stopping won’t seem out of place.
You should only need to use this method for the tracks that experience key changes; other tracks should be able to continue using the other method.
