Editor VERY Slow

FMOD Studio
1

Hey
I am using fmod for a project and the editor is VERY VERY slow. It seems that this started occuring once the project started getting bigger. We are using Unity and to be honest there isn’t that many assets yet regarding what games could be. We are using Fmod 02.02.19

Basically whenever I want to add audio files, edit events (whether size of a referenced event or else) any action takes like 5/10s for Fmod to register. As you can imagine this is not great.

2

This might help:
Here is how things are setup:
image

image
image2981×1116 187 KB

then once “funlayered” is selected nested event works like this:

image
image2918×914 282 KB

which then selects between the different nested events (of funlayerd)
And for example main logic looks like that:
image
image2941×614 57.7 KB

problem here is that it is impossible to work as fmod is just so slow I can’t do transition timeline editing as it takes me litterally a minute to edit one.

3

Hi,

Users have noted short wait times specifically when opening extremely large/complex events in the event editor, but a 5-10 second wait on general actions definitely sounds like an issue that we need to look into. A few things:

  • Can I get you to upload your project to your FMOD user profile so that I can take a look on my end? Note that you’ll have to register a project with us to do so.
  • Can I also get you to upload a log from Studio where you experience the issue? See the bottom of this section of the Studio docs for info on where to find logs on your OS.
  • Are you using source control with your project? If so, what integration type?
4

Hey I will upload it with the profile on which the game is registered then
-Would you like the logs in the placce where I will upload my project?
-We are using github but no integration within fmod so that should not be an issue

5

Hey @Leah_FMOD
this is the account of the game I’m working on. I have uploaded both the log file as well as the fmod project

Please let me know if there is anything else I can do

Thanks again

Maxime

1 Like
6

Thanks for uploading your project and logs! I’ll take a look at them and get back to you.

7

thanks!

8

Thanks for your patience.

The slowdown you’re experiencing is due the extremely high amount of event referencing you have, specifically the event Main Logic and the “card” events referenced within - the latter contain 50 references each and are referenced multiple times themselves.

The slowdown in Studio is definitely an issue that I’ve passed to the development team, as adding an instrument to an event that doesn’t interact with any of the referenced events shouldn’t be doing anything that causes slowdown, but ultimately the culprit here is the extremely high complexity of your event structure.

While I can’t offer any specific suggestions as to how to optimize your events as I’m not familiar with your, I would recommend offloading some of the complexity to runtime if possible so that Studio doesn’t have to handle the entirety of the “mx” event all at once - for example, separating your music and sfx events, splitting your card events into 5 separate instances for each of the five cards, or just firing off individual card events from code as needed, etc.

As an aside, are you running into any performance issues when playing the “mx” event at runtime? Or is it just in Studio that the GUI has problems?

9

Hey
thanks for your feedback

While I can’t offer any specific suggestions as to how to optimize your events as I’m not familiar with your, I would recommend offloading some of the complexity to runtime if possible so that Studio doesn’t have to handle the entirety of the “mx” event all at once - for example, separating your music and sfx events, splitting your card events into 5 separate instances for each of the five cards, or just firing off individual card events from code as needed, etc.

the problem is that the five cards you see are actually not SFX but samples that play inside the music (they are part of the music). So could offloading to runtime be done with the use of programmer instruments for example? or would that still create problems?

As an aside, are you running into any performance issues when playing the “mx” event at runtime? Or is it just in Studio that the GUI has problems?

The SFX structure is actually a lot more complex in terms of event reference but looks to work fine. Same with the music everything seems to work relatively well. I am still debuging and testing. By that I mean that at runtime for now it works well. The problem is really the GUI.

I think I also “simplified” some of the music logic to have more audio tracks within the initial event but the 5 “card sfx” within the music is part of the system so I can’t just delete them:

image
image1344×851 75.3 KB

To be honest this works better but it’s still slow.

10

Also this is missing 3/5 th of the music which is why I was a bit scared of the slowdown

1 Like
11

As far as optimizations at design-time in Studio go, my first thought would be to see whether it’s possible to consolidate uses of event instruments, so that you’re able to accomplish the logic you need while reducing the total amount of event instruments. I’m not entirely familiar with the intended event structure so these ideas may not fit, but this could be done a few ways:

  • Consolidating uses of multiple multi-instruments or event instruments to one instrument that uses async/async cut to achieve the same behaviour
  • Converting event instruments that basically only play assets to single/multi-instruments - i.e. the use of “bugs” in “bugsIntro”

Another thing that could be done is to swap event instruments for command instruments, which should reduce GUI lag. This would have some functional differences:

  • Event audio will be routed directly to the mixer instead of via the referencing event
  • You won’t have explicit control over the local parameters of the instance started by the command instruments, only global parameters
  • You have less explicit control over the lifetime of the event instance

Given the amount of tempo-sensitive looping events and routing complexity, this may not work for you, but if you refactor events instruments playing simple loops into one-shots that are triggered on a loop and stop naturally, it should reduce the GUI slowdown. The “cards” events, or the parameter sheets contained within, for example, might be good areas to test this, since they’re events that contain a high amount of referencing complexity.

Using programmer instruments instead of event instruments for the individual card events would be my first suggestion. This would impose some complexity in making sure you’re playing the correct asset, but should ensure that the asset stays in sync with the parent timeline.

12

Thanks for the suggestion :pray:
I think a lot of what you’re saying makes sense, I’ll see how and if I can make it work within the context of the game. Especially the program instrument as I am already selecting by code which sound to play via parameter so that would mean adding the functionality to select the sounds specifically for the program instrument I guess (I have never used those so I might be wrong)

When you mean that it would be routed directly into the mixer could I specify a place in particular or will it be directly into the master with no possibility of selecting a bus? (Again I have never used those so I am not familiar with their functionalities)

Little bonus question: from what I understand it is not possible to force reroute tracks into a different bus than the event, is that correct or am I wrong? (For example having a layer routed into a different bus than the other tracks of an event)

Thank you again for your responses and your time

13

You’d likely be swapping setting a parameter for retrieving an audio file from an audio table using the corresponding key. I would recommend reading over our documentation on Audio Tables and taking a look at our Unity Programmer Sounds example script for more information.

  • If you’re using an event instrument to play any event, it will route into the referencing event.
  • If you’re using a command instrument to play a non-nested event, it will route to its existing routing in the mixer.
  • If you’re using an command instrument to play a nested event, the nested event will be routed directly to the audio output (bypassing the master bus).

It’s sort of possible. You can’t reroute at run-time using the Studio API, and all tracks in an event must route into the event’s master track. However, you can use sends/returns to send the output of a specific track to a return bus in the mixer. At run-time, you can use parameters to automate send/return volumes, or adjust the volume of return buses in the mixer, to achieve an outcome similar to rerouting the signal.