I’m building up a music manager for our game. This area is half the game, pretty much, so there’s lots of music for it. It’s split into four zones and I’ve built up two versions of the main tune for each zone and there’s a stretch of ambience (same sub event each time) and then a stretch of silence.
Currently, I’ve only received music for two of the zones but i thought i’d set up the logic as if there were all four and just duplicate the two zones for now. Mainly to get the set up done but also to stress test this approach.
There’s a lot of logic because ideally, if you cross zones part way through a main tune, it’d be lovely to have the music transition at a similar or same point in the tune, quantised. If you’re 3 minutes in and cross over the zone line, it’ll transfer at the end of the next bar to around 3 minutes into the zone you’re now in.
Transition windows are about 15 seconds. The whole event is about 1 hour 20 minutes. Main music takes up less than half of that.
I think I could make the main tunes subevents and create a parameter that tracks the progress and repositions the playback bar accordingly with changing zones.
The audio is set to preload and the profiler is coming back with pretty fine results.
I’m just really wondering what the most CPU efficient way of approaching this is?
Anyone have any related experience or thoughts on this approach. The music is really feeling like it’s becoming organic and curated - even thought it’s pretty automatic now - so I’d really like to keep this going. I’m worried that it might be shortsighted of me.
The most CPU-efficient way is always going to be limiting the number of entities your event requires: Removing as many unnecessary tracks, instruments, and events as you can without altering behavior.
For example, I notice that you have a large number of audio tracks for different instruments. If any of those tracks have identical effects in their signal chains and identical routing destinations, combining them into a single track that contains all the instruments from both tracks would slightly reduce the complexity of the mixer graph, and thus reduce the CPU cost of processing the mix.
You might also want to try ensuring your music event’s assets are not set to stream. Setting an asset to stream significantly reduces the memory cost of playing a single instance of that asset, but incurs an additional cost in CPU time and disk I/O, and may actually increase memory use when playing multiple instances of the asset at once. (Assets longer than 10 seconds in length are set to stream by default when imported into FMOD Studio, but you can change which assets stream in the assets browser.)
That being said… The gains of optimizing a music event for CPU are typically very small, as there is usually only one piece of music playing at any given time. If you’re concerned about your project’s CPU costs, you may be better off optimizing other events in your project.
I notice you’re using a very large number of transition markers and destination markers instead of transition regions and destination regions. I’m guessing this is to ensure that transitions can go from one beat or bar of a music track to the equivalent beat or bar of a different music track.
This isn’t related to your event’s CPU cost, but are you aware that you can set transition regions to use a “relative” offset mode? This mode ensures that transitions go from one beat or bar of the transition region to the equivalent beat or bar of the destination region. It even takes into account differences in tempo and time signature. Using transition regions with relative offset mode and destination regions instead of transition markers and destination markers might reduce the amount of work involved in setting up this kind of complex transition logic.
Ohhhhhh! I didn’t know about transition regions having a relative offset. I might convert it to that so that i can get the hang of that for the future…also just to declutter haha.
You’re right though, it’s to keep the relative position in the piece of music. They’re set up as 2 variations for each of the 4 different flavours of one piece of music. There are a lot of stems to keep a hold of. None of which do actually have any effects on them. Only a couple of reverb sends to the mixer. The audio is set up to preload rather than stream so I thiiiiink that it should be okay as is.
If it’s typically quite small, I might see how it feels once all the music is in and set (this set up is duplicates of main tunes rather than all of the music) and then maybe I can consolidate some audio files or I can at least consolidate some events.
