# No persistent event instance with callbacks? **URL:** \ **Category:** Unreal Engine\ **Created:** [October 14, 2021, 8:27pm UTC](https://qa.fmod.com/t/no-persistent-event-instance-with-callbacks/17801 "2021-10-14T20:27:17Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Alcibiade](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/alcibiade/32/4284_2.png) [@Alcibiade](https://qa.fmod.com/u/Alcibiade)\ **Post date:** [October 14, 2021, 8:27pm UTC](https://qa.fmod.com/t/no-persistent-event-instance-with-callbacks/17801/1 "2021-10-14T20:27:17Z")
I’m working on a “dye and retry” kind of game, coded in blueprints, and at the moment we reload the level at each death. Which means the level is destroyed and recreated, thus I need some persistent data, which has to be stored in the game instance. Storing a FMOD event instance in the game instance works well and plays the music continuously across level reload. But the problem is that I need to use callbacks, **and callbacks are only available on FMOD components, and components are only available on actors, and actors are (by definition) placed in a level. So when the level is reloaded, the FMOD component is destroyed.** To summarize, it seems impossible to have a persistent FMOD event instance **with** callbacks… Did I missed something? Is there a workaround? Maybe is it possible to retrieve FMOD callbacks from a C++ class, which is not an actor? (since actors are automatically affected to a map and destroyed with it) ---
**Author:** ![Alcibiade](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/alcibiade/32/4284_2.png) [@Alcibiade](https://qa.fmod.com/u/Alcibiade)\ **Post date:** [October 19, 2021, 11:05pm UTC](https://qa.fmod.com/t/no-persistent-event-instance-with-callbacks/17801/2 "2021-10-19T23:05:09Z")
Couldn’t it be possible in a future release to expose callbacks in blueprints directly in FMOD event instance, instead of only in FMOD component? That would allow us to put a music track in the game instance (which is the only persistant class across all the game), for a more seamless audio experience. ---
**Author:** ![jeff\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/jeff_fmod/32/1766_2.png) [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)\ **Post date:** [October 19, 2021, 11:51pm UTC](https://qa.fmod.com/t/no-persistent-event-instance-with-callbacks/17801/3 "2021-10-19T23:51:50Z")
If you need persistent actors between level restarts (level restarts that are triggered by a scene reload), you could try creating a global level that holds a persistent audio component and load/unload a child level as required using [level streaming](https://docs.unrealengine.com/4.27/en-US/BuildingWorlds/LevelStreaming/HowTo/StreamWithBlueprints/). Here is the level hierarchy, with “GameLevel” added to a some other persistent level. ![image](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/d/d02f1a35a09c21df52b39383a8a84d590d22fe24.png) And here is an example blueprint, in this case the level is being switched on and off rather than immediately restarted. ![image](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/8/8aba6e0f6f7c8382b3197e2df27bd8a0d482dac1.jpeg) That should give you smooth playing, callback-able audio across level restarts. Otherwise, the only other thing I could think of would be to change the level restart behaviour to not rely on scene loading. ---
**Author:** ![Alcibiade](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/alcibiade/32/4284_2.png) [@Alcibiade](https://qa.fmod.com/u/Alcibiade)\ **Post date:** [October 20, 2021, 12:16am UTC](https://qa.fmod.com/t/no-persistent-event-instance-with-callbacks/17801/4 "2021-10-20T00:16:17Z")
I already tried a bunch of things, including persistent level. But not a unique streaming level in the persistent level yet. I’ll definitively give a try, thanks @jeff_fmod. We’ll probably change the restart behaviour one day (but it’s a lot of work, and it’s only a prototype at the moment). I eventually found a crazy solution, by exposing beats as parameter changes, with command instruments! ![image](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/5/5af17b074d875c22717aaf181b4b293d9e84f640.png) With a loop to “listen” the parameter changes: ![image](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/4/46d66f9705d480f04a8c2eff42bf012995f47a67.png) However, is there a technical reason for not exposing callbacks on event instances? ---
**Author:** ![jeff\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/jeff_fmod/32/1766_2.png) [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)\ **Post date:** [October 20, 2021, 1:26am UTC](https://qa.fmod.com/t/no-persistent-event-instance-with-callbacks/17801/5 "2021-10-20T01:26:08Z")
Wow, that is a crazy workaround, not ideal but glad you got something working. > [@Alcibiade](#): > > However, is there a technical reason for not exposing callbacks on event instances? FMOD Audio Component is a wrapper for a `Studio::EventInstance`, so those callbacks you see on the FMOD Audio Component are actually exposed callbacks on the underlying event instance. The fact that the FMOD Audio Component cannot exist outside of a scene is, as you have said, because it is a type of Component. > [@Alcibiade](#): > > Couldn’t it be possible in a future release to expose callbacks in blueprints directly in FMOD event instance, instead of only in FMOD component? Because EventInstance is tied to the Studio API I do not think we would be able to expose the callbacks in blueprints without creating another wrapper or modifying the FMOD Audio Component’s inheritance hierarchy. I have let the dev team know of the limiation here, while you could resolve this issue by using the C++ API, the further people can get with blueprints the better! ---
**Author:** ![Alcibiade](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/alcibiade/32/4284_2.png) [@Alcibiade](https://qa.fmod.com/u/Alcibiade)\ **Post date:** [October 25, 2021, 11:40pm UTC](https://qa.fmod.com/t/no-persistent-event-instance-with-callbacks/17801/7 "2021-10-25T23:40:19Z")
Ok, so I tried your solution, @jeff_fmod, of putting every actors that should be reset in a child stream level (FMOD actor being in the persistent level), and unload/reload the stream level only. It does work but brings another problem: it’s impossible to get (by blueprints) the current stream level name or reference. So actually, my code only works… for one level! So, definitively, there’s no blueprint-only solution to this problem (else than my crappy workaround). ---
**Author:** ![Alcibiade](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/alcibiade/32/4284_2.png) [@Alcibiade](https://qa.fmod.com/u/Alcibiade)\ **Post date:** [October 26, 2021, 8:24am UTC](https://qa.fmod.com/t/no-persistent-event-instance-with-callbacks/17801/8 "2021-10-26T08:24:04Z")
I finally got away by making my sub-level stick to a strict naming convention, so I can retrieve its name from the persistent level. ---
**Author:** ![jeff\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/jeff_fmod/32/1766_2.png) [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)\ **Post date:** [October 27, 2021, 3:20am UTC](https://qa.fmod.com/t/no-persistent-event-instance-with-callbacks/17801/9 "2021-10-27T03:20:49Z")
Ah, yes when I tested this idea it was only for one level. Sounds like a good workaround, but you are right this is definitely something we need a good blueprint solution for.