Just wondering ahead of having a developer implement this event if it will work the way I’m hoping it does.
Excuse me if this would be too specific to our implementation to answer on here.
The event is a single labelled parameter sheet with a single instrument on each label.
What I want to happen is the event is started and then the developer just updates the parameter each time we need the sound on set parameter to play.
What I notice is that if I change the parameter while a sound is playing back I hear the new sound. However, after the initial sound stops I have to start the event again (via play button) to get the newly updated parameter to playback (obviously).
The use of this event may see many sounds called within the duration of one, but it will also see use where the event has finished before the next sound would be needed.
My question is how would the developer instance this event?
If they tell it to start each time a parameter is updated the currently playing sound would be cut off.
So in this case they would be better just updating the parameter.
However, in the case that there is no currently playing sound they also need to start the event.
It seems the use cases may clash with this event design.
This is entirely doable. You just need to set the event to be persistent. You can set an event to be persistent in the macros section of the deck while the event’s master track is selected in the event editor window.
If an event is set to be persistent, it does not stop of its own accord when it finishes playing sounds, and instead continues to play (albeit without producing any audio) until you issue a command (such as setting the value of its parameter) that triggers one of its instruments to play.
To clear up a point of potential confusion, the FMOD Engine is capable of playing multiple instances of the same event simultaneously. Indeed, the default behavior is that starting a new instance of an event doesn’t stop any other playing instances of that event. If you want to see this behavior in action, you can audition it in the sandbox window by dragging multiple instances of the same event into the scene.
There are ways to limit the maximum number of instances of an event that can play to one so that starting a new instance does cause existing instances of the event to stop, but they’re not the default behavior, and it sounds like you don’t want to use any of those ways in this case.
Are you able to provide a short example of how a developer would set a parameter on an already playing event without creating a new instance of it?
Im sure earlier in development we had some issue with a Persistent even using Global parameter building up in volume when multiple calls for the event are made within the duration of one of the sounds. I think this is why i avoided using the persistent event.
I can see however it was likely the method used to call the sound that was the issue.
If it’s a local parameter, the developer would typically just call Studio::EventInstance::setParameterByName or Studio::EventInstance::setParameterByID. Either of these will set the parameter’s value within the event instance, provided that event instance exists. If the event instance is in the playing state, setting the parameter’s value will trigger whatever instruments are at the parameter’s new value.
If it’s a global parameter, you’d instead call Studio::System::setParameterByName or Studio::System::setParameterByID. Either of these will set the parameter’s value. If an event instance that uses that parameter is in the playing state, setting the parameter’s value will trigger whatever instruments are at the parameter’s new value.
Hmm… That should only happen if your code was setting the parameter to a new value, then immediately setting it to a different new value, multiple times in quick succession, resulting in many different voices/channels being created. Does that sound like what your code was doing?
Im but a simple sound designer, so I am not entirely sure of the exact reason this was happening. I have reached out to the developer. I think you were on that support ticket tho.
Thanks a bunch for those examples and this does make sense. So i will proceed with the current event design with some knowledge on how to direct developers to use it.
Cheers.
Hello, I am the developer working on this.
Basically issue is slightly different than being discussed here:
The issue is sound stacking i.e. there are scenarios in our game where we call same event multiple times and the audio in that event gets played that many times so it gets heard so loud.
We want to control this situation in fmod project, if a sound event is already playing and game calls this event again, it should not play it again.
The tool for this is instance limiting. Instance limiting can be applied on the bus, event, or instrument level; in your case, I suspect you would prefer either instrument-level or event-level instance limiting.
Event-level: If you select an event in FMOD Studio and look at its event macros in the deck, you’ll see “Max Instances” and “Stealing” properties. If you set “Max Instances” to “1” and “Stealing” to “None,” then whenever your game’s code attempts to create a new instance of the event while an existing instance is already playing, the new instance will not be created. (In your case, where you’re using a single persistent event instance to play multiple sounds, this won’t do anything, as your code never never creating more than one instance. This method may be useful in other circumstances, however, and is by far the most common instance limiting method.)
Instrument-level: If you select an instrument in FMOD Studio and expand its “Trigger Behavior” drawer in the deck, you’ll see “Polyphony” and “Stealing” properties. If you set “Polyphony” to “1” and “Stealing” to “None,” then whenever the event instance triggers that instrument while an instance of that instrument is already playing in that event instance, the new instance will not be triggered. (Because the instance count is specific to the event instance, this method will not work if you are creating multiple instances of the parent event.)
