I’m actually using steam on a project right now and no, there’s no functional mix control in FMOD. If you move the Direct Mix Level knob it’s just a gain knob. At 0 it’s silent. It’s supposed to balance the direct signal like a wet/dry mix, if I’m not mistaken. It feels like the FMOD plugin is a bit broken or ill-conceived. Another example: setting Occlusion type also renders the output silent in Studio if you set it to Simulation-Defined.
In the user manual under both Direct Mix Level and Occlusion type it says “Only available if using Unity’s built-in audio engine.” so that explains it.
With the occlusion type at least, not sure why they didn’t just let audio pass through as if non-occluded. If you want to work on any events that will use it, seems like you’re expected to deactivate/reactivate in Studio. Maybe I’m missing something.
Still prefer using Steam Audio for its sound over the alternatives.
Hey Mago, I’m having an issue where my built-in direction parameter is affecting the entire event, even though I’ve only automated panning/direction on the one stereo track
What’s your event’s track routing? (You can check the routing of each track by right-clicking on the track head and looking in the “Reroute” submenu of the context menu to see which track has a checkmark next to it.)
Hey joseph. I think I found the problem, but can’t figure out how to fix it.
The built in direction parameter is controlling the 3D preview →
If I create an entirely new 3D event, then add a built in direction parameter, that doesn’t happen. But I can’t find the automation that is making it happen in the event with the issue.
In fact, without the automation, it seems to be ONLY effecting audio being sent to a spatializer, which is the opposite of what I want lol.
As for routing:
all the mono tracks are being sent to the one “mono out” track, with a spatializer, then sent to the master.
The one stereo track with the “direction” parameter automating the pan, is being sent straight to the master.
I’ve taken screenshots for you. Really appreciate your help with this.
This is normal and expected. The state of the 3D preview is automatically updated based on changes to the values of event’s built-in parameters, and vice versa. This ensures that they remain consistent, which is important, as they both represent the same things.
I’m not sure why it doesn’t happen with new events that you create. When I test it here, built-in parameters affect the 3D preview as expected.
There is no automation. In fact, it is not possible to automate the 3D attributes of an event, and thus not possible to automate any of the properties displayed in the 3D preview. Instead, both the 3D preview and built-in parameters reflect the 3D attributes of the event. If the event’s 3D attributes are changed by any means, it’s expected that both the 3D preview and the event’s built-in parameters reflect that change.
I’m afraid I don’t understand what behavior you expect. If you change the event’s direction built-in parameter, how do you expect the 3D preview to indicate that change to direction, and vice versa?
I’m afraid I don’t understand what you’re trying to do. It sounds like you want the direction built-in parameter to affect only the audio that isn’t sent to a spatializer, but I can’t wrap my head around what movement of the event that would represent.
The direction built-in parameter represents the angle between the listener’s direction of facing and the direction from the listener to the event instance; while the spatializer pans and attenuates the signal based on the event instance’s position relative to the listener. Which is to say, both of these things are controlled by the position of the event instance relative to the listener. Are you trying to change the direction to the event instance relative to the listener without moving the event instance relative to the listener, and if so, how?
If you want to be able to change the value of the parameter without also changing the position of the event instance relative to the listener, you could potentially do so by using a user parameter instead of a built-in parameter. User parameters’ values are independent of the position of the event instance in 3D space, and so can be set to new values without moving the event instance and altering the behaviour of its spatializing effects.
