Fmod's Polyphony Cooldown

Hi everyone, so I use the polyphony cooldown feature in fmod (it’s on the event macros) for events that should have some polyphony but I don’t want the instances to be triggered too close to each other.

This works fine for 1 player, but in the game I’m working on there is a big battle arena with several players so I am afraid that some of the instances could get silent just beacuse another player in the other side of the map is triggering the same event in the exact cooldown’s time window.

So, I wonder, is there any way of making this cooldown “local” to a determined radius of the game world instead of the whole thing?

Am I making sense?
Thanks!

I’m using 1.08.08. Thanks fir the tip, I didn’r realize that. It could definitely work.

That’s good to hear! Please let us know if this solution isn’t sufficient for your project.

I was very pleased to see Cooldown added to Studio. Prior to this, in our games we implemented a cooldown feature with a radius value, so that we can have a Max Instances/Playbacks value greater than 1 while being protected from far away sounds blocking a nearby instance of that same sound from playing. Setting Stealing to “quietest” isn’t ideal for me because I would need to limit Max Instances to 1, which would result in tails being cutoff (or the sound not playing at all) when the same sound is played in series.

TLDR, having a radius value for the Cooldown feature would be greatly appreciated by our studio.

Thanks,
Sean

What version of FMOD Studio are you using, and have you considered using the ‘quietest’ stealing behaviour? It’s designed for this exact circumstance: When a new instance of an event whose stealing behaviour is set to ‘quietest’ is created, it will steal the instance that is least audible, taking into account attenuation due to distance.

1 Like

I’m not sure I understand your use-case. You mention that you used cooldown to prevent more distant instances from blocking nearby ones, but as the function of cooldown is to prevent instances from spawning together too close to each other in time rather than in space, I’m not clear on how this worked.
When you say your implementation of cooldown had a “radius” feature, what was it the “radius” of, and what did it do or mean? Was it the radius of a circle drawn around each emitter? Or of a circle drawn around the listener? What was the effect of an emitter (or the listener) being inside or outside of the radius of another emitter
(or the listener?)
Would setting stealing to ‘furthest’ work for your use-case?
Why did setting stealing to “quietest” necessitate setting Max Instances to 1? I presume there was some detail of your project that made it necessary, but what?

Our use-case was as you described, i.e. to prevent near simultaneous (or simultaneous) events from triggering more than one sound instance and causing volume spikes/distortion. However, once we implemented cooldowns internally we became aware of the undesirable side-effect when it comes to simultaneous instances that are somewhat far apart. Sorry if I made it sound like we primarily used cooldowns for controlling sounds that are located far apart.

The radius was for the circle around each emitter that triggered a cooldown. So if an audio event triggered a cooldown with a radius of 250 distance units, then during that cooldown no other instances of that event would be permitted within 250 units of that particular emitter.

As for stealing, I may be misunderstanding how cooldowns work in Studio. My assumption is that if an event has a non-zero value for the cooldown, that the cooldown takes precedence over Max Instances. I.e. If cooldown is set to 100ms, during that 100ms only 1 instance is permitted and all other subsequent requests to trigger that event are ignored. Once the cooldown has expired, the Max Instances limit takes over and allows additional instances to trigger (as per the Max Instances value). In other words, Max Instances and Stealing work together, but they have no impact on Cooldown (correct?). That’s how our internal cooldown system worked. I.e. If a cooldown was active on the event that we wanted to trigger, then it would be ignored and the call to trigger that event never got passed to FMOD. Unless, of course, the location of the event instance was outside of the cooldown radius setting of the instance that initiated the cooldown.

If my above understanding is correct, then in order for me to prevent two or more instances from triggering simultaneously, while also using Stealing to ensure that distant instances couldn’t block an instance that’s closer to the listener, then I think I would need to disable cooldowns and set the Max Instances to 1, correct?

Just in case it’s helpful, in addition to the scenario where, say, an explosion happens far away and another one happens right up close to the player (simultaneously), the radius feature can also come in handy if the two instances are equidistant from the player/listener, but one is panned hard right and the other is panned hard left (both with some distance attenuation, so that they’re not super loud, but still very audible). If the player looks at the one on the left, but only hears the one on the right (because of the cooldown), then it would read as a bug to the player.

Sorry for the wall of text. Let me know if I anything I wrote is unclear.

Thanks,
Sean

1 Like

Thanks for answering my questions. I’ve added your request for more complex location-specific cooldown to our feature/improvement tracker, and it’ll be discussed and potentially scheduled for development at our next quarterly roadmap meeting.

I must admit to being curious about something: How did your system of cooldown deal with the situation where two explosions occur in each other’s radii, but on opposite sides of the listener? If I understand your system correctly, only one of them would be audible despite both being visible. Is that correct?

1 Like

Great! Thanks, Joseph.

For that situation only one of them would play a sound, so I would need to tweak the radius size until it was a decent balance between being protected from volume spikes/distortion, but also minimizing situations where it would be obvious that an explosion was missing its sound. So if the game was a side scroller/platformer, I might make the radius about 2/3 of a screen width, so that explosions at opposite ends of the visible screen would both get a sound. I would also likely adjust this value depending on how hard the panning and distance attenuation was.

Thanks again!

1 Like

Solved in comments ^^^

1 Like

@joseph Was this added to the roadmap? We just faced this exact issue with footsteps in our game, and the radius based cooldown solution would be exactly what we need.

Yes. As I mentioned in my previous post in this thread, I added radius-based cooldown to our feature/improvement tracker. This suggestion was subsequently reviewed by our technical director and approved for implementation, but has not yet been scheduled for development.

1 Like