I have a parent event which is 2D, no spatializer called “Waterfall”
I have a labeled parameter that switches between playing one of three nested events, each with their own spatializer and distance attenuation. The parameter is called Size, and each value is called Small, Medium, Large.
This works just fine, each nested event will play their correct attenuation.
However, the gizmo in Unity won’t correctly show this, and just shows the parent attenuation, the default 1-25. It also means that the Override Attenuation variable doesn’t work, so I can’t really customize it further inside Unity.
Is this a bug, or is it just the way things have to be and I would have to go back to having 3 separate events (Waterfall_Small, Waterfall_Medium, Waterfall_Large) that aren’t nested?
It’s not a bug - the distance event macro of referenced/nested events being played via instrument isn’t exposed to the “Override Attenuation” functionality in the Studio Event Emitter.
If you don’t want to change the mix/max distance of your event dynamically at runtime, and you’re only wanting to tweak it in Unity then it may be more practical (and resource-efficient) to use three separate events instead of using a parent event.
Alternatively, if you don’t need a visual guide with the distance gizmo to tweak the distance, you could use a single spatializer on the “waterfall” event (either on the master track, or on a specific audio track) to spatialize all three nested events, and use the “Size” parameter to automate any spatializer properties that need to change for each size.
If neither of these work well for your use-case, could I get you to elaborate on your event setup? For example, is there a specific reason why you need individual spatializers on all three nested events? Pictures or a video would be helpful in demonstrating the overall structure as well as key behaviours/automations.
Thanks for the reply and suggestions.
I don’t need to change them dynamically at runtime, so it sounds interesting what you propose with having a single spatializer that gets automated by the parameter, I might indeed just do that! It still won’t be as custom though.
And I do need the visual guide of the gizmo, that is partly what I’m trying to get to work. Obviously I will still use my ears to check whether it sounds right, but the gizmo helps a lot in getting around the ballpark.
Unfortunately, there’s currently no way to have both the gizmo’s visual guide and your own min/max distance value. The “Override Attenuation” functionality in the Studio Event Emitter internally uses Studio::EventInstance::setProperty, which explicitly functions as an override, meaning that your automation/modulation to the min/max distance event macro wont apply. Likewise, retrieving a property with Studio::EventInstance::getProperty will only retrieve the value set with setProperty.
Both things could definitely benefit from some improvement, i.e. exposing the internal value of property after automation/modulation when it isn’t being overriden, and allowing the gizmo to read from this value, so I’ve added this to out internal feature/improvement tracker.
As a workaround, the simplest option is probably to test the distance in Unity, and then adjust in FMOD Studio accordingly.
Alternatively, you could set up your own spherical gizmo, and then manually set its size based on a parameter you’re using to automate the min/max distance in FMOD Studio. This is possible since the value of the parameter can be set/retrieved at runtime, and the drawback of not being able to match specific automation curves shouldn’t be an issue for your purposes since you’re swapping between three different discrete values.
Apologies, the “internal” value of the min/max distance is already exposed via Studio::EventInstance::getMinMaxDistance. Currently the distance gizmo isn’t actively updated using this, so I’ve noted that on our internal improvement tracker instead.
As a workaround, you can use the values retrieved from that function along with Gizmos.DrawSphere or similar to draw your own distance sphere.