Async being ignored on events containing loops

Note: I’ve edited this after finding out more about my issue.

I have a bunch of song events inside a Multi Instrument of another event called “Battle”. The intent is to have “Battle” randomly pick a song via the Multi Instrument’s Playlist. This is what the event looks like:


Async doesn’t work when I have a loop region in a song. I.e. when the Timeline cursor within “Battle” reaches 7 secs, the looping songs are stopped.

I can probably work around this via adding a Sustain Point to “Battle”, but I wanted to flag this issue in case it’s a genuine bug. I’ve tried this with version 2.02.12 and 2.02.19.

Thanks,
Sean

Do any of the events in your multi instrument’s playlist include a “backward jump” transition - which is to say, a loop region, transition marker, transition region, or magnet region that can potentially cause that event’s playback position to jump to the left on the timeline? If so, that’s probably the cause of the issue you’re seeing. Because FMOD is unable to predict when an instance of a referenced event containing a backward jump transition will end, FMOD automatically stops any such event instance when the instrument that spawned it is untriggered.

This is intended behavior. However, as we’ve received a large number of requests that we change it, we’re planning to do so as part of FMOD Studio version 2.03.00.

In any case, removing the backward jump transition from the referenced events should ensure the instrument continues playing.

Incidentally, I notice that the multi instrument in your screenshot is set to “Sequential - global scope” mode. In this mode, it will work its way through the entries in its playlist in the order they appear instead of selecting them at random. Since you mentioned you want it select one at random, I’m guessing this is an error; setting the playlist to “randomize” or “shuffle” should get behavior closer to what you want.

Thanks, Joseph. Yes, I’m using a loop region, so that would be causing the backward jump. That planned change sounds like it would work well for me. Even though I can’t think of a scenario where I’d want to retain the current behaviour, I’d be happy to know what that might be.

For the “Sequential - global scope” setting. Thanks for flagging that. I had temporarily switched it to that for testing purposes.

Thanks again,
Sean

It’s not useful for sound design purposes, but it is useful for avoiding memory and CPU leaks. If event instances don’t automatically end, there’s a higher chance of them accidentally “leaking” and remaining present even when they’re no longer needed. In this specific case, however, we have decided to use other methods to prevent leaks than limiting the behavior in the way we do currently.

I’m glad to hear you were able to get the behavior you wanted.

1 Like