So I have a loopable event, which we use for ambient sounds in a runner like game. Objects that play this event are spawned up ahead, further than event attenuation and player is running towards them. We setup instance limiting (lets say 3) and virtualization steal mode. This works semi ok. But the “steal” happens too late, it happens when objects behind the player are removed/destroyed. Since there’s a “buffer” zone/distance, that cleanup happens too late in this case. I was hoping that I could handle this some how in directly in fmod. I tried using Direction setting, so that those events are audible only in front field of view, basically muting them when listener goes past them. But it seems that virtualization logic is not affected by this?
I’m afraid we’ll need more information to help you with this issue.
What behavior are you trying to achieve?
You mention you’re using instance limiting, but why do you want to limit the number of playing event instances?
You mention that you’re using “Direction setting.” do you mean you’re using a Direction built-in parameter? If so, what are you automating on that parameter?
If you provide more information about what your goal is, we may be able to suggest ways in which you could achieve it.
I have a runner type game, 3rd person camera behind player. who is running “forward”. Player is running on segments which are instantiated up front (we always have 3 segments instantiated). When players passes the current one and starts running in the second one, previous one is unloaded and next one is loaded. On these segments I have a bunch of props which also emit sound. Sound attenuation is pretty much limited to half of the segment size, so you only hear stuff from the current segment.
“What behavior are you trying to achieve?”
I’d like to limit playback to only closest & front facing sound emitters. Once a sound emitting prop goes out my field of view (i.e. i run past it), I don’t really need to hear it anymore.
“but why do you want to limit the number of playing event instances?”
Well, isn’t this a common practice? To limit spam, to save resources, etc? I don’t want to hear everything
“You mention that you’re using “Direction setting.” do you mean you’re using a Direction built-in parameter? If so, what are you automating on that parameter?”
Yes, I’m using built in Direction parameter. I’m automating volume, basically killing the volume on the ±40 angle. This works great, so when prop goes out of player FOV, it gets muted.
I’m pretty much wondering if at this moment, when distance parameter kills volume, that event instance can be reused by the virtualization logic.
regarding the virtualization, the docs say that:
“Virtualize: New event instances will be virtualized, meaning they are created and played but produce no output until an existing event instance stops.”
So, can a Direction parameter or any other similar logic cause instance to stop?
It’s a universal practice - but one that is automatically taken care of my FMOD’s virtual voice system. Any voice whose volume drops below an inaudible threshold is automatically virtualized; and if the number of playing voices would exceed the number specified using System::setSoftwareChannels, the quietest playing voices are also virtualized.
Placing an instance limit on events is therefore redundant in most cases. There are game-specific reasons to do it, but I’m not sure which apply to your game.
VIrtualizing an event instance does not stop that event instance. Virtualized event instances cease to consume more than a token amount of resources and do not produce audio, but their parameter values and volume levels are tracked so that, if the event instances are ever un-virtualized, they can resume playing as if they had been non-virtual the whole time.
Any parameter can cause an event to be stopped, provided the event is non-persistent and designed such that it stops as a result of specific parameter values. A non-persistent event stops automatically if it is not currently producing any output and there is no further content on its timeline, so if you design an event such that specific parameter values put it in that state, you can use those parameter values to stop that event.
Hei, thanks for info.
I’m trying to put your advice into action, but all I managed to find is, using command instrument to stop event, which stops all events. How do I stop it per instance?
Command instruments won’t work for this, as you have discovered. The easiest way is to put events into a state where they will stop naturally. As I mentioned earlier in this thead:
The easiest way to do this is to place a destination marker to the right of all other content in your event, add a transition region to the event that stretches from timeline position 00:00.000 to just to the left of that destination marker, and then give the transition region a parameter trigger condition such that it becomes active when you want the event to stop.
