Hello,
I have a pretty annoying bug and figured out what it was, It happened when I have an event referencing other events, when the timeline enter the refereced event it gets triggered (we can see the inner timeline of the nested event), but no audio is playing inside the “master” event… (also it’s a persistent event with an voice limit to 1)
The way to solve this problem is to open the referenced event directly, press play, the audio play, and then you can stop and return to the master event to press play and have audio inside the master event… but sometimes it don’t work either.
Also when playing the referenced event I sometimes get 1-2s lag before audio play so this hint it’s a file access problem ? (but playing audio in the asset tab work very fast)
Ok so I did more tests and it seems it’s related to the fact that the event is quitte heavy and take a lot of time to start (sometimes 10s !).
When pressing play and not hearing any audio I have the habit to press spacebar again to stop and replay the event, this might cause the event to stop in a “semi-loaded” state… and when pressing play again the new instance start but the samples are not loaded… no audio will be played at this point.
10s is a very long time for an event to load, would it be possible to get a screenshot of the referenced event that is taking up to 10 seconds to load?
I mean the main event contain like 20+ referenced events of background music of the game, the lag before starting the main event varie between 6-14s but seems unrelated to the current referenced event actually being triggered. I suppose It’s because all the ram data of all events have to be loaded before playing the main event ?
As you can see each referenced event also sometimes contain nested events inside them (and nested nested nested etc…).
Also the project is on a SSD, cpu is a i9-9900K with 32go of ram.
Thank you for the video. In Studio, we try to save some resources by waiting till an event is selected to load any data attached to it rather than having everything in memory all the time. Which may lead to the behavior you are experiencing now with this larger event. What I can suggest when selecting these heavier events is giving them some time to load before trying to audition them.
Hello,
Understandable, by looking at the windows task manager it showed that when loading this main event fmod memory goes up to 2go so yes it’s quitte a heavy event.
I dont have this problem in game, only inside fmod studio.
However this seems not entierely related to the “non-trigger” bug, I managed this morning to repro with a very simple event containing nested events and even the simple instrument did not play audio… (cf video)
This happened just after using play mode on unity with live update on fmod. I’m wondering if stopping unity or live update might cause the loaded sample to be wiped out without updating their loading state ?
This video show my typical experience with this bug, the event dont trigger sound but opening the nested events does. Randomly opening theses directly sometimes fix the main event.
Would it be possible to get your project uploaded to your profile to test on my side? You will have to register a project with us to be able to upload files.
do you mean uploading the fmod project or the unity project ?
My current project is already registered but by the programmer account, I don’t know if its possible to link it to my account ? I guess a project should no be registered twice
The FMOD project, apologies that wasn’t clear. What is the email your programmer account uses? You are correct, you don’t want to register the project twice.
We are also having this issue. I’ve noticed it across many events as we make heavy use of embedded events and it’s incredibly frustrating. The work around it to have opened the embedded events before playing the event that holds them. Really not an ideal workflow as it’s very slow.
We are on 2.02.13 it’s important in order to reproduce that you have not opened the embedded events.
This behavior is a side effect of how FMOD Studio loads events: FMOD Studio cannot play content from an event that isn’t yet loaded, and loading takes time, so if you audition the parent event before its referenced events have finished loading, those referenced events will not play.
To fix this, we would need to prevent you from auditioning the parent event until all its referenced events have finished loading their content. I can think of a few ways we could potentially do that:
Popping up a modal dialog containing a progress bar when you select the parent event, making it impossible to audition or edit the parent event until the progress bar is full.
Having the play button in the parent event be grayed out and non-interactive until the referenced events were finished loading.
Having an audition not start immediately when you click on the play button, but to instead wait to start until all required content has finished loading.
Would you like me to add one of those suggestions to our feature and improvement tracker?
I think popping a dialog would be the best on first thought. Although I suppose this would prevent you switching to another event?
Once it’s loaded that would be cached somewhere I presume? So I wouldn’t have to wait each time I opened this event, right?
That’s right: Modal dialogs block all interaction with parts of the application other than the modal dialog itself, so a modal dialog would prevent you from auditioning the event and editing the selected event until the progress bar was full, and would prevent you from selecting another event unless you either waited for the progress bar to fill or clicked the modal dialog’s ‘cancel’ button.
Yes and no. As of the time of writing (November of 2025), once FMOD Studio loads an event into memory, that event is retained in memory until you close the FMOD Studio project. Thus, once you have selected an event and waited for the progress bar to fill, you would not have to wait when selecting that event again subsequently within the same FMOD Studio session; but if you closed the project and reloaded it later (perhaps because you needed to turn off your computer) and then reselected the event, you would have to wait for the progress bar again.
We open and close the project a lot during the day as we switch between branches in our source control. Otherwise we have issues with FMOD having the wrong data loaded. Which I would assume is probably quite normal for anyone working on a project with multiple team members.
Perhaps option 3 would be better in that case. As long as it’s obvious
”Having an audition not start immediately when you click on the play button, but to instead wait to start until all required content has finished loading.”
