Hey,
This isn’t really an issue, more of a question out of curiousity.
When I look for information on setting parameters for oneshot events, on this forum or elsewhere, the recommendation seem to be to Create instance → Set parameter → Start instance → Release instance. A reoccuring statement is that a parameter can’t be set after the instance is released. However if I try set a parameter after releasing the instance it works just fine.
Here’s an example of how the code could look:
var instance = RuntimeManager.CreateInstance(event guid);
RuntimeManager.AttachInstanceToGameObject(instance, gameobject.Transform);
instance.start();
instance.release();
instance.setParameterByName("Parameter name", value);
In the profiler I can see that the correct value for the parameter is set even for the first instance.
So this begs the question, is it fine to keep setting parameters this way? Any example where this wouldn’t work? I’m curious how others are doing it and what would be considered best practice.
Hi,
That statement is likely in relation to RuntimeManager.PlayOneShot()
, which immediately releases the event instance it creates and doesn’t return a reference to the instance for you to set parameters on.
While you can set parameters after an event has been released, generally best practice is not to do so. This is because by calling instance.release()
, you have signaled to FMOD that it can destroy the event once it has stopped, and as a result you no longer have control over the lifetime of the event. This can lead to situations where you’re trying to set the parameters of an event instance that no longer exists.
Hope that helps!
Thanks Louis. That makes sense. You’re right that it has been in relation to the PlayOneShot method.
Final question though. Say I have an event that uses a parameter sheet with different sounds depending on the parameter value. Setting a parameter after the event has started, like the example above, would logically mean that the event would start with the default or last parameter value applied. After that the parameter is set to a new value which means another sound should play. So two sounds should start playing here. Nonetheless I can only hear the sound selected by the new parameter value even when using “Hold value during playback”.
I tried setting up a delay for the parameter change and it seems that if the parameter is set to ~0.05 seconds from starting the event it listens only to the new parameter value. If the delay is longer it has the default value. How does this work? Is there some sort of delay to starting the event which makes it possible to set the parameter within that time?
The behaviour you’re experiencing is due to how FMOD Studio’s multithreaded processing model works - you can read about it more in the Studio System Processing section of the Studio docs, but essentially your API calls are enqueued in a command buffer when the Studio system updates, and then acted on in a separate thread.
In this case, there’s likely two factors at play:
-
Event instances don’t necessarily start playing when eventInstance.start()
is called, they may be in another playback state (i.e. loading, starting), in which case the parameter set to hold on playback won’t start holding until the event asynchronously starts playback
-
Your setParameter
call less than 0.05 secs after instance.start()
is enqueued in the same update as instance.start()
, causing the parameter change to essentially be applied alongside the event starting instead of afterwards (i.e. when you set the parameter > 0.05 seconds afterwards)
Thank you for explaning, that makes it clearer!
1 Like