I am trying to get an echo return in the mixer to appear in an event and be spacialized with the event’s other sounds in a game level.
I have thought about just putting an echo in the events already, but this is about having all SFX that appear in the SFX bus to receive some echo, and that echo being spacialized in the game, not just a stereo effect.
It seems to me that my echo return in the mixer will have a send to a Return (call it Return A), and then in my event, add a return track with that Return A.
Result…This Return A will then be mixed into the event and then the event will be placed into the game and be spacialized.
The problem I seem to be having is that the Return A, automatically appears in the mixer and is mixed into the Master. I don’t want the return to appear in the mixer, but to patch directly to the return track in the event.
I made it this way: create Bus in mixer turn fader all the way down and put Tranciever plugin pre fader. Adjust it as a transmitter. you’ll send all you sound to these send. Then create 3d event with Tranciever as a receiver put reverb/echo plugin after it. Now you can use you reverb event on an object and spatialize it. Hope it will help you.
Transceiver effects are powerful in the same way that sledgehammers are powerful: They allow you to create connections between places that would not normally be connected, but it’s often better to use more precise tools, even if they’re less powerful.
Foxymusic’s method will work, but only if there is only one playing event instance using the return bus at a time. A return bus creates a submix of the signals it receives from every send instance that targets that return in every instance of a playing event and applies its effects to that submix. That post-effect submix is what a transmitting transciever effect will transmit, so every concurrently-playing event instance that uses Foxymusic’s method will also receive the bus-processed signal from every other concurrently playing event instance that uses that method and the same transceiver channel.
If you want to avoid the signals from different events being mixed, do not use a return bus. Instead, when you create your sends in the event, have them target a return track. Return tracks are part of the event instance’s internal mixer, and so only receive signals from that event instance. As a side effect, this lets you avoid creating a return bus that routes into the project mixer.
I’ll tell you what I am trying to achieve. In VR, when the player is in a cave like environment, they can make any decision that could create a sound to be played. ie drop something, make a movement etc or any insect or environmental sound can be spawned in that same cave like area.
Because of that I would like to to send any of the sounds that make it to a certain SFX bus to be sent to an echo unit. This should give the player a feeling that they are in a cave.
That is easy to do as you know, but the echo effect the player hears is essentially stereo in the VR headset speakers.
I am wanting the echo to be spacialised in the cave by having it came from event or ‘speakers’ in the cave environment so it stays in the same place as the VR player turns their head.
In a game, using this example, it would not be that important, and the player would probably not notice.
I gave this example as a simple explanation. To elaborate further, in the game I am working on, there are a lot of very open mouthed like caves, and the echoes would emit from the back face of the cave, not all encompasing the player, so I want the echoes to keep emiting from a spacialised position in the open mouthed cave like the back wall, not all around the players head which is what the stereo echo does.
The trouble I am having is trying to work out how to get a send from a SFX bus back to a return track in an Event, without it making its way into the Main Mix.
It is almost impossible to pre determine every event and how they could play in that ‘cave’.
Second to that, every ‘cave’ will have different settings for delay and reverb etc since some are massive and some are very small and tight.
Which means that every virtually every event in FMod will have to have echo’s and reverbs added to them and I would guess many global parameter settings etc
Thats a massive job fraught with danger, messy and I would guess very resource expensive.
If I am to use a SFX bus, then every sound that arrives at that bus, no matter what it is or how it sounds, will be sent to an event with 1 echo and reverb unit on it and then be placed in the game level for spacialization.
Simple, neat and resourceful
you need to build complicated system in fmod and your game to manage all your requests. You need to use buses for sure for good perfomance. You should check your player, NPC’s and all sounding objects for being in a room (as many as you have). After check you can send all sound from your player ( for example) to send for exact room bus he in with parameter. And as I was suggesting before you need to spatialize you buses and attach them to the points or objects you’d like an echo to come from. But it all requires a lot info from you game. Building realistic enviroments isn’t simple thing to have ready to use solution. And this is for sure Fmod’s weak point at this time. cause it has no portals no spatialized buses no occlusion options and all this systems need to be built by sounddesigners
Buses create a mix of all the signals they receive, and apply their effects to that mix. This is cheap (because there is only one signal, there need be only one instance of an effect in the signal chain), but also means there is no way to “un-mix” the signal to get the individual effect instances’ outputs and route them back into the event instances they came from.
If you instead put the effects into each event, it will result in each event instance’s signal being processed within that event instance, without being mixed. This is, indeed, more expensive, as there needs to be one instance of an effect for each signal to be simultaneously affected, and that means one instance per concurrent event instance. If you use this method, it is best to simplify its creating and maintenance by using preset effects and effect chains, which allow you to use the same effects in multiple events without having to manually duplicate them and without having to manually update them in every event whenever you make a small change.
These are the only two options you have. Both are valid, but both have different advantages and disadvantages. There are no other options but these.
FMOD doesn’t have spatialized buses because the function of a bus is to mix all the signals it receives into one, so that you can adjust and apply effects to that one signal instead of having to apply them to each individual event instance individually.
Because effects on a bus affect the bus’ mixed signal and not the individual event instances, any effect on a bus affects every event instance routed into that bus in the exact same way - which is to say, a spatializer effect on a bus would make your project sound like event event instance routed into that bus was in the exact same location. While you might occasionally want to do this, it is far from common, and it is easier to achieve by using events and event instruments.
The only way to make a bus spatialize every event instance’s output differently would be to keep the signals separate. Doing this would undermine the benefit of a bus: Keeping the signals separate would mean that there would need to be one instance of the spatializer effect for each signal, and thus one for each event instance routed into the bus.
As such, we have no plans to support putting spatializer effects on buses at this time.
The FMOD Core API does have support for geometry-based occlusion. You can read about it here.
The echo mixer return -> transceiver -> 3D positioned receive events that play the echo, is a valid approach. It’s being used in Avalanche games. The echo points are placed automatically into the in-game terrain, but they can be placed manually too. There is a Virtualize max instance limit so only the closest 4 echo points are audible.
The 3D positioned echo playback events each have their own Delay DSP that is automated by distance - thus, the further away the echo point is, the longer it is delayed. This is followed by a distance filter (lowpass, highpass by distance). The Distance automation on the Delay can cause warbling artifacts but you can give it a ‘staircase’ envelope so that it snaps from one value to the next instead of changing slightly every frame, this eliminates the warbling.
All sounds that are meant to have echo, send to the mixer echo return, so the signals do get mixed together. All echoing sound in the cave play from all echo points. However this is not a huge problem, since only loud sound events (gunshots, etc) have a high send level to the mixer return. It is only an approximation of actual, ray traced echoes from every sound source, but it gives a nice effect regardless.
When outside the cave, a snapshot can be used to lower / mute the volume of the echo return bus.
Similarly, instead of using a transceiver to pass the sounds back to the events, you could use dummy events with snapshots that faux-spatialize reflection returns in the mixer. So the audio signal never gets passed back to the event, but you use snapshots in the event(s) to pan/position respective returns in the mixer.
This keeps you from having to pay for a bunch of receivers (which can get expensive), but you have to make a snapshot/return per-event so you don’t multiple events fighting to pan the same return.
