Please advise: I think what I need is to change the behavior of volume ADSR’s (on sounds with max instances of 1) such that they override envelopes which are currently in-process. e.g. if a sound is fading, and is then re-triggered, the attack phase of the new instance overrides the release phase of the old instance, and the original release phase is abandoned. Is that possible? Is there an envelope-behavior toggle somewhere?
I currently have this problem: a looping background-ambience event is playing via a reference from a persistent master-control event (see image), based on a parameter sheet (‘AmbID’) on the control event. When the parameter changes (discrete) it switches to a different referenced event. Each event reference has an ADSR fade-in and fade-out. But if the parameter is updated to being the same as its current value, that event fades out to nothing. i.e. the release phase is processed and the instrument stops.
I moved the ADSR’s off the references in the master-control event and put them on the sub-events instead. That helped in some ways, but I still get the sound dropping out if the second trigger occurs during the release phase.
I tried raising the max instances of the referenced events to 2 instead of 1, and this may be a solution, but it seems like a hack and I am worried about loops getting stuck on.
Making separate copies of the wave data (i.e. double the asset footprint) would probably work, but obviously that is undesirable.
Other than eliminating all crossfades (not ideal) how would I go about avoiding this? Suggestions?
Why would it be a hack? If you want to start this sub-event while the same sub-event is still playing its release, you indeed need at least 2 instances. Does it work correctly when configured that way?
I don’t want to start the sub-event, I want to just keep playing it without changing anything. The game frequently updates the AmbID value, frequently to the same value, and sometimes I need the ambience to not change anyway.
I say ‘hack’ for two reasons:
It’s smoke and mirrors: what I want is for the event to just keep doing what it is doing, not spin up an unnecessary second instance.
I am worried about that first instance getting stuck on. The whole point of this set up is to not have to worry about starting and stopping events: I just change ID numbers on the persistant master-control event, which handles the starting and stopping for me. That way I don’t have to imagine all the different possible ways that the game might leave a loop in an stuck-on state.
Re: does it work correctly: Maybe. I haven’t tested enough to be sure yet, but I’m doing that now. I just really worry about stuck loops…
I’m quite surprised fmod retriggers the sub-event when the parameter is updated to the same value, but that may be true. However, wouldn’t it be very easy to just check that in the game code and update the value only when it’s changing?
No, you’re right, it doesn’t re-trigger the sub-event. The stuff I’m dealing with is more complicated than that. It’s more about rapid switching between two values of the parameter: a-b-a. The ‘a’ event re-triggers the same sub-event before that sub-event has finished its release phase. I want it to just start back up with the new attack phase, but what it is doing is ignoring the new envelope and finishing its old release phase instead.
You don’t need to worry about loops getting stuck on. With the setup you have, it is impossible.
If you move the playback position off an instrument, that instrument is untriggered. There is no way to un-untrigger it; once you have untriggered it, however momentarily, it will inevitably perform its stopping behavior. Moving the playback position back onto that instrument will trigger a new instance of the instrument that has no connection to the old instance.
So, there should be absolutely no problems caused by setting the max instances of the referenced events to a value greater than one. I am not sure why you do not want to do so.
It doesn’t. For an instrument to be untriggered, the instrument’s trigger conditions must cease being met. Setting the parameter value will therefore only untrigger the instrument if the set value is not one that would trigger the instrument.
Ok, good, thanks for that. I have gone with this solution so it’s good to have some reassurance. Going to max-instances=4 pretty-much solved the core problem, and also I was using the ‘none’ stealing mode. It works better on ‘oldest’ instead. I keep most of this stuff on ‘none’ because I don’t want multiple copies of my persistent master event, but the events referenced in the master event’s instruments can apparently sustain a few crossfading copies.
I don’t even understand why you try to limit the number of instances of your nested events. When the parameter sheet untriggers the nested event, it is stopped (even if delayed stop cause the release you’ve set). You could just let infinite instances, it would work as intended.
“None” stealing mode will prevent the new instance to play, which you don’t want. But if it does so, it’s the sign you’re limiting the instances too much. “oldest” will be less noticeable. But why would you want to cut an instance playing its release? One more time, don’t limit the instances at all here, it’s not appropriate. As says Joseph, you don’t need to worry. I’ve never seen an untriggered event continuing to play indefinitely. Hum, in fact, yes, once, it was a bug I reported
As I said, I tried to limit the number of instances of my nested events because, when using looped assets, it generally seems safer to me to not allow more than one copy to play. (To avoid doubled or stuck-on loops) You are correct that when an event is un-triggered, it definitely will stop playing. But some of these events are only un-triggered when the game un-triggers them. I trust FMOD. I do not trust our game. More likely, our game could start multiple copies.
In this particular instance, the key idea is that we repeatedly update the parameter values such that they frequently remain the same. (e.g. the current value is ‘1’, and we update it with a value of ‘1’.) There are some configurations of envelope locations which can result in unwanted-on sounds. I can demo that easily.
P.S. - Alcibiade - You said above something about your “bad English” - That may be the reason some of your phrasings seem inappropriately combative. Examples: "I don’t even understand’, “One more time”, and the repeated use of “Why would you”. I’ll assume you didn’t mean them they way they sound to me.
If you’re only triggering the event through nested events, this should be impossible… Unless you’re playing more than one instance of the top-level event?
We would greatly appreciate knowing more about these configurations of envelop locations, as knowing more about your setup may reveal why you’re experiencing the strange behaviors you describe.
Sure. I didn’t see them as strange behaviors, I figured it was an inevitable consequence of having an overly-complicated set-up.
But… I think I found my error:
I was in the middle of typing up a complete description for you of how I have these test events set up, when I think I discovered the crucial thing: I didn’t have ‘Cut’ on for some of my event instruments. When I turned that on, the behavior changed to be what one would expect and want.
In short: the events continued to play because they were looping events which were not set to “Cut Playback when Untriggered”
All that said, I want to repeat this: I never thought FMOD would be likely to produce stuck-on loops in the game. My concern is that our game will produce stuck-on loops by failing to send the necessary FMOD API calls when needed.
On a nested event which contains a loop, a transition, is persistent, or whatsoever (in short: isn’t “oneshot”), the cut button shouldn’t do anything. Which is easy to understand: the event has to cut anyway, otherwise it would loop indefinitely (the stuck loop that you fear!). If it does something different with the cut button checked or unchecked, it’s probably a bug, which could be similar to the one I found (and was fixed) some time ago.
By the way, I would advocate hiding this button in the case the nested event isn’t oneshot, in a future fmod update, it will make things clearer.
Going to max-instances=4 pretty-much solved the core problem, and also I was using the ‘none’ stealing mode. It works better on ‘oldest’ instead. I keep most of this stuff on ‘none’ because I don’t want multiple copies of my persistent master event, but the events referenced in the master event’s instruments can apparently sustain a few crossfading copies.