I’ve been looking into audio specific accessibility features and settled on the idea of opening up far more groups or VCAs for the player to tweak in the audio settings menu (so the player being able to reduce the volume of specifically the Player Breathing group for example if they find that the sound is unpleasant to them).
Generally for reverbs in my projects, I have reverb sends set up on the master track of the event post-spatialiser, then have reverbs set up on return tracks. I’ve realised that having these deeper mixer options could cause a lot of issues when it comes to the event reverb sends still routing the same amount of signal through to the reverb return when the parent mixer group / VCA for the event has been turned down.
As an example, there’s a -12dB send on the “Player Breathing” event. Pulling down the “Player” group by 9dB won’t reduce the signal to the reverb return. The reverb return will be routed into a different group since many events throughout the project will be using that reverb due to having a system where different rooms have different reverb responses.
Here’s a rough example of how the mixer would look to the player for a reference (all of the options are groups, players would not have access to individual events):
So how could you additively change the reverb send on the event level if say, the group the event is routed into is reduced by the player by -3dB, the parent group of that group reduced by -6dB, and then the parent of that group reduced by -3dB?
I should also note that I’m working on games for more limited hardware such as the Oculus Quest and the Switch, so having one reverb per group could be an optimisation issue, especially if there’s any kind of switching system between different reverbs too.
Does anyone know of an easier way to set up a reverb or mixer system to be able to handle this?
The simplest option is to put your sends in the signal chains of group buses “downstream” of the faders whose volumes you want players to be able to adjust. Each group bus creates a submix of the signal routed into it and adjusts the volume of that submix according to its fader value, and a send sends the signal from its position in the signal chain, so a post-fader send on a group bus will send a copy of that group bus’ submix to the return - including any volume attenuation applied by that bus’ fader, as well from event and bus faders “upstream” of that group bus.
To use your diagram as an example, you would place a send in a post-fader position on the “SFX volume” group bus (and optionally the “Music Volume” group bus, if you want your music to be subject to reverb), and would route the return bus containing the reverb effect into the Master Volume bus (which I assume is the project’s Master Bus). This would allow your players to set the volumes of any bus in the project, and have it affect the volume of every event sent to reverb.
This solution consumes slightly fewer resources than giving every individual event its own send to the reverb bus, but does have limitations: Not giving every event its own send to reverb means that it is not possible to set each event’s send to a different level, nor to automate the values of sends in order to set them to different values in different instances of an event.
However, if you need to be able to set each event’s send send to a different level, but do not need to set different instances of the same event to different send levels, the simplest option would instead be to create one group bus for each event, and place the send in the post-fader position in each such group bus’ signal chain. You would then need to create VCAs for the categories of volume you want your players to be able to adjust, and assign the relevant group buses to those VCAs. This is slightly more work to set up than the method above, but (because VCAs can be assigned to other VCAs, and because an event can be assigned to multiple VCAs) means you can give your players the ability to control the volumes of arbitrary groups of events and have the those adjustments be combined when two or more groups overlap.
To use your example again, you would create one group bus for each event in the “Player Breathing,” “Player Footsteps,” “Raptor Vocalizations” and “BGM” group buses, and position these buses in the routing structure such that each event is routed into its corresponding group bus, and that each of those group buses is routed into the group bus into which its associated event was formerly routed. You could then create VCAs for multiple arbitrary collections of these event-specific group buses, allowing your users to (for example) duck the volumes of the “SFX Volume” “Player,” and “Player Breathing” group bus/event groups, and hear player breathing SFX be ducked three times over.
Creating an additional group bus per event in your project does come with additional resource overhead, but it’s almost certainly cheaper than including multiple reverb effects in your project.
Finally, if you need to be able to set each individual instance of an event to have a unique reverb send level, that’s somewhat trickier. The only option would be to automate the volume of each event’s master track’s volume fader on one or more global parameters. This solution would take a considerable amount of work to implement, but would require almost no resources.
If none of these solutions work for you, there may be other options available, depending on your requirements. If you let us know what your project needs, we should be able to suggest something.
Yeah, we’d need to have individual instances of events to have different amounts of sends. We’ve had systems before where the 3D event script runs a check to see what type of room it’s within, then applies a local parameter value which we use to change the send amount. So applying a value to a local labelled param like “corridor” or something, then we automate the send to send X amount to the Corridor reverb return.
I’ve had a play around with using multiple global parameters to set the value pre-spatialiser and it seems like it’ll be doable, but definitely a considerable amount of work as you said. Good to know that it is workable in Fmod though!