I’m curious to know if there is any way event stealing can still honor the release of the AHDSR, but from the FMOD Editor? I don’t work on the API side at all so if I can pull it off in editor, that would be great!
I have a laser sound that loops for a strategy game. I want to limit the events to maybe 4 or 5 instances, but when I move the camera around there are hard cuts going out of the old ones and into the new ones. I thought adding a little release to the AHDSR could help but it doesn’t seem to. Setting the priority type to “furthest” helps with this a little bit, but I wanted to know if event stealing can still allow a slight fade out so it doesn’t cut into the new instances so hard?
Event stealing is a resource management tool, a way of pruning away old event instances so that they don’t consume resources. An event instance playing out the release period of its AHDSR modulators is an event that’s still playing, and therefore still consuming resources - and so stolen event instances always* stop immediately to prevent that from happening.
If you want event instances to stop with fadeout when more than a certain number of them are playing, you’ll have to keep count of how many are playing in your game’s code and stop them with fadeout when needed, rather than relying on the event stealing behavior.
*There is technically one situation in which a stolen event instance does not stop immediately, but it’s not relevant to your situation.
Just wanted to bump this to say for what it’s worth, I’d also find this to be a helpful feature, if even just a toggle. I find it’s equally as helpful for mixing as it is resource management, and the only thing missing is having a graceful fadeout.
Understandable if that’s way out of the intended design though, I’ll just need to start tracking those instances in-game like you mention.
I asked for this back in 2021, with some arguments that seemed to make sense to the FMOD staff at the time: Suggestion: steal release time
Perhaps this feature could be reconsidered?
Looking at our records… You’re entirely correct! A discussion was had internally, and the outcome of that discussion was our deciding to add new stealing behaviors that would let stolen event instances play out their stopping behaviours gracefully.
This task is therefore already on our feature and improvement tracker, but as of the time of writing (March of 2025), it has not yet been scheduled for development.
I’ll add you and @modulesplusmusic to the list of people interested in this feature. (@Alcibiade is already on the list, due to having requested it back in 2021.)
I would also like to add my name for this feature, I think it’s very much needed. In my mind voice limiting is not just about resource management, it is also equally about mix clarity.
Moreover, I wish virtualized voices could also gracefully pause and resume playing rather then cutting out and back in causing audible clicks and pops.
My use case atm has to do with managing many engine looping sounds at once. These loops start and stop quite frequently. Player can see all these vehicle at once so it is important to know which loops are more likely to needing to be heard. I am limiting very aggressively so to avoid a crowded mix. Virtualizing the events is the only stealing behavior that somewhat keeps things sounding consistent without causing strange scenarios where player is expecting to hear something moving but no sound is being played. I have tried all the other stealing behaviors.
However, having lots of loops going in and out of virtualization causes audible clicks.
Is there any possible work around to be found in the API?
Yes and no? I wouldn’t call it a workaround, as it only uses features of the FMOD Engine for their intended purposes.
You want to limit how many event instances are playing audible at a time, in order to keep your mix clean and player-readable. That’s a reasonable goal - so write code that determines which of your playing event instances are important to gameplay and which aren’t. (I don’t know your game, so I can’t know what criteria you might use, but I suspect you already have a clear idea just from my suggesting it.) Then, create automation that lets you ramps the unimportant event instances down to silence by setting their parameter values.
The silent instances will automatically be virtualized without pops of clicks, because the virtualization system is designed to be used with silent and near-silent voices; and they’ll be able to un-virtualize and return to audibility again once you mark them as important.