To make sure I have this straight… If a voice is virtual, is uses nealy no CPU and memory, correct? Given that the latest branch has the ability to automatically virtualize a voice when it’s audibility is zero, can this new feature be used as an effective means of managing large numbers of ambient voices, as described in [url=http://www.fmod.org/forum/viewtopic.php?p=31253&highlight=#31253:18up4h1k]this thread[/url:18up4h1k]?

So let’s say I have 200 torches in a level with looping samples whose voices get started when the level loads. Let’s also say they all have max distances of 5 meters. They’re spread out so that I can never audibly hear more than 4 at a time.

Now because they’re ambient, they’ve not been able to steal each other’s voices. 4 max playbacks means basically the last 4 to load get the voices (after 196 steals occur during load). It was suggested to me that we implement a higher-level voice control that would automatically start and start ambient voices according to the avatar’s distance from them.

However, now that silent voices automatically become virtual, could I theoretically put the max playbacks of the torch voice to 200 without having a problem, provided I control the number of torch voices via tight rolloffs? If I have 200 max playbacks and 196 of them are virtual, I’m only allocating enough CPU and memory for 4 audible playbacks, right?

If you had nothing but torches playing it would be a benefit, but if you’ve only got 32 real voices available for example, the other 168 would automatically be virtual, and any other game sounds would automatically be real if the others were silent. Thats the point of the virtual voice engine, it prioritizes based on audibility and importance.

To answer the other question, yes virtual voices are free, they just do pos+=timedelta and loop logic in the update function.

You never mentioned ‘events’ anywhere, though i should have picked up from your use of the term ‘max playbacks’.

It doesnt help you there, but the issue you raise is something we will be addressing soon.

You are right you would still have to set your max playbacks to 200.

What we are going to do in a coming version, is add ‘virtual events’ which includes a new addition ‘max audible’ to the event property sheet along side ‘max playbacks’ but the meaning of max playbacks will change (transparently to the user).

That way you can specify ‘max audible’=4, and ‘max playbacks’=200.
The more significant memory that is currently used under max playbacks, will only be allocated for 4, but you will be able to get 200 handles back from getEvent and update them.
These virtual events will be small and just enough to update the position and call start/stop on them so won’t use much memory at all (ie probably less than a hundred or so bytes per event).

[quote="brett":32617syb]What we are going to do in a coming version, is add ‘virtual events’ which includes a new addition ‘max audible’ to the event property sheet along side ‘max playbacks’ but the meaning of max playbacks will change (transparently to the user).

That way you can specify ‘max audible’=4, and ‘max playbacks’=200.
The more significant memory that is currently used under max playbacks, will only be allocated for 4, but you will be able to get 200 handles back from getEvent and update them.
These virtual events will be small and just enough to update the position and call start/stop on them so won’t use much memory at all (ie probably less than a hundred or so bytes per event).[/quote:32617syb]

That sounds really good, we’ve got around this in the past by always stopping and starting events at distance though there’s still the possibility that we might in some occasions get 11 things at once when we have 10 max playbacks and that the event that has been stolen or didn’t start will be around when it would be obvious that it’s not playing.