We’re using StopEventsOutsideMaxDistance as we have emitters on some prefabs that are quite numerous like wind rattle on fences (100s of fences in the scene in the distance which will never be heard) so it’s a way of consuming less resources.
However in some events I have looping audio and stopping logic e.g, a spray can which has a shoot impact to start, looping spray and a little impact when stopped to close the spray.
This is just one example of looping audio with stop logic, from previous testing with other events exactly like this it seems going outside max distance and coming back into it causes the event to play from the beginning and therefore hearing things that make no sense like the impact of firing the spray while technically in the middle of the spray, now this is obviously the expected behaviour and it’s not a problem for some looping events like room tone etc but for others like this it is a problem and I just wanted to be clear on my options here.
Turn StopEventsOutsideMaxDistance off and control the amount of emitters which will be active, maybe query emitters outside the walkable areas and turn them off for good. this would mean we can just let the default virtual voice system do the work, to my knowledge virtualised events will continue to play but consume no CPU and therefore will play from the correct position when audible again.. am I correct there? Also I’m aware that virtual voices have a limit too so this would fill those up quite quickly! our scenes can be quite large so lots of emitters would still be loaded into memory when 100s of units away.
Control distance attenuation with the built-in distance parameter manually and Increase these events max distance by a certain amount which would mean by the time it’s audible again it would be inside the loop and we wouldn’t hear the initial impacts etc
Split off any audio that’s related to stopping or cancelling into a separate events and just trigger that via code when we stop the loop… although this is the simplest it would be rather boring work, create more unnecessary events and would be a shame not to use these cool FMOD features like stop logic etc.
Maybe all of these are fine solutions but just thought I’d ask in case I’ve missed any important info or other solutions!
It sounds like you have a good grasp of the options that are available, so I’ll focus on giving you more information about their potential advantages and disadvantages.
Letting the virtual voice system do its job is the option I recommend, provided that your virtual voice count never needs to exceed the maximum virtual voice limit - which can be set as high as 4095. The virtual voice system been through decades worth of optimizations and refinements, and is good at what it does.
You’re almost entirely correct! You’re definitely correct as far as the use-case you have in mind is concerned.
Click on this line to read technical details that're unlikely to be relevant to your game.
As you’ve read, when an event’s voices are virtualized, the FMOD Engine keeps tracking the event’s parameter values, including that of its timeline parameter, which continues advancing and respecting logic markers such as loop regions. When the event’s voices are un-virtualized again, the event’s instruments begin playing again, using the event’s parameter values as usual. Exactly how such events behave depends on their synchronicity:
Synchronous insturments (like the one in your screenshot) continue playing from the point overlapped by the timeline playback position, exactly as if the event had never stopped playing.
Asynchronous instruments begin playing as if they had just been triggered, which usually means their associated assets begin playing from the beginning (or from the position determined by their “Start Offset” properties). This usually isn’t a problem, as asychronous instruments are typically only used in events where they are expected to play ascynchronously, and so structured to take that asynchronous behavior into account.
As described in our documentation on this topic, you can set the virtual voice limit as high as 4095. Just as you say, if that’s not high enough for your game’s purposes, you will have to look at some other method of limiting how many event instances play.
This could potentially work, but only for events where max distance isn’t the point at which the event becomes inaudible. Naturally, if the event uses its max distance to determine the maximum distance at which instances of that event are audible, increasing the maximum distance will cause the event to be audible at greater distances, and so won’t prevent the event from audibly starting from the beginning when it starts again due to moving back within its maximum distance. By contrast, if the max distance has no relevance to when the event because audible, increasing max distance will work as you want.
If your event depends on a spatializer (or object spatializer) effect for distance-based attenuation, it is likely that it uses the event’s max distance to determine the maximum distance from the listener at which the event is audible. To change this, expand the spatializer effect’s (or object spatializer effect’s) distance override drawer in FMOD Studio, enable its override, and set the effect’s min and max distance to the same values as the min and max distance properties in the event’s macro controls. Only then will you be able to increase the max distance in the event’s macro controls without also increasing the distance at which the event attenuates to silence.
If your event instead depends on automation on a distance parameter for distance-based attenuation, the solution should be easier. You’ll only need to change the maximum value of that parameter, and choose not to rescale content on that parameter.
If your event instead depends on automation on a distance (normalized) parameter for distance-based attenuation, the solution will require you to both change the maximum distance property in the event’s macro controls, and to manually rescale content on the distance (normalized) parameter to fit into a smaller section of that parameter.
In any case, be aware that this method may not work as desired if there is a chance of max distance decreasing so rapidly that the event becomes audible before it has finished playing out its pre-loop section.
As you say, this would work, but would be a lot of work to implement.
