Getting parameter ID from StudioEventEmitter

Im using the following code in Start()

dragEventEmitter = GetComponent<FMODUnity.StudioEventEmitter>();
FMOD.Studio.PARAMETER_DESCRIPTION paramDescription;
dragEventEmitter.EventDescription.getParameterDescriptionByName("speed", out paramDescription);
drehReglerParamID = paramDescription.id;

Later im using the cached parameter. But it does not work, using string does work. I looked into the debugger and paramDescription looks like it get default values (all zeroes).
After some research it looks like that retrieving the param IDs of events from a Studio Event Emitter component does only work when Preload Sample Data is checked. What exactly does this setting do? Does it create an instance at Awake? If so how is it possible to retrieve the event information like parameter ids without instantiating an event?

If you look in StudioEventEmitter.cs, the EventDescription you are getting from the Emitter is only set in Lookup(), which is called if Preload is true or if the Event Description reference is not valid when playing the Event. GetEventDescription takes the Event Path as argument and returns the EventDescription for that Event, so you really don’t need to access the StudioEventEmitter or to instantiate an Event, but you could get the Event path declared in the Emitter and use it to get the Event Description:

dragEventEmitter = GetComponent<FMODUnity.StudioEventEmitter>();
var description = FMODUnity.RuntimeManager.GetEventDescription(dragEventEmitter.Event)
FMOD.Studio.PARAMETER_DESCRIPTION paramDescription;
description.getParameterDescriptionByName(“speed”, out paramDescription);
drehReglerParamID = paramDescription.id;

This is exactly what i was looking for. Thank you very much, will look into this later.

A further question. This is pretty much the first time integrating the emitter component. Previously I exposed for every event a FMODUnity.EventRef string in the editor and created / released the event or played as oneshot when needed. This is because in almost every case the sound is triggered by script and not by one of the callbacks that you can select in the components drop down. Thats why i did not bother using the component. But this time i gave it a try even though in this case start and stop is still left to None.
When using the emitter component does it create the instance at startup? Im using the component with this event on a total of 5 objects. And i was experiencing that sometimes the event did not play and after setting the #ofmaxinstances from 1 to infinite it was working as intended.
Also are there any advantages using the component in these cases (start/stop left to none)?

Previously I exposed for every event a FMODUnity.EventRef string in the editor and created / released the event or played as oneshot when needed.

Yeah, that’s exactly how I work most of the time (but I rather use Scriptable Objects to collect the Event Refs)

When using the emitter component does it create the instance at startup?

From my understanding the instance is created and started only when the Play method of the Event Emitter gets called, and that depends on the start callback or when manually calling Play from another script (please correct if wrong).

Also are there any advantages using the component in these cases (start/stop left to none)?

Personally I like to manage instances like you mention you did previously, but there is nothing wrong in using the Event Emitter and just calling Play, Stop or SetParameter from outside.

I put using SOs for event refs into my todo/refactor list a while ago. The main reason was to use one if multiple objects use the same event(s) to save some memory on the event path string. But i was unsure if using just one big SO and every script picks the needed string or make one SO per event ref.

Im curious what your intention is in using SOs for event refs.

But i was unsure if using just one big SO and every script picks the needed string or make one SO per event ref.

One big SO is too chaotic and one SO per event ref too overkill in my opinion. I tend to categorize the event refs in different Scriptable Objects, for example a PlayerAudioData SO that includes all the player event refs, an EnemyXAudioData SO, LevelXAudioData SO and so on.