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.
Thanks Joseph.
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?
