Stoping nested events when parent event stops

[g.hadji]

Hello.

Here is my setting. I have two continuous 3d events. Each of those event consists of a multi instrument looping randomly. A “biomeId” parameter is switching from one event to the other, depending on the ground surface/biome ingame. Since I need the events to sound continuous, I made them loop using a timeline transition. It sounds okay but this method prevent me from using the “biome A” and “biome B” sounds within the same event, because if the biome parameter is changing while we are in a timeline transition, fmod has to wait the end of the transition to then go to the other biome’s loop, and it could create weird non reactive sounding situations ingame.
There, I decided to use nested events for each of the biome, and to use a parent event to manage the transition with command instruments (play/stop biome A/B). I don’t need to use transition timeline within the parent event and I adjust the fade-in/out of the events using ahdsr on each one of my nested events. It sounds okay BUT it lacks something very important. The parent event is the one called by unity, and the nested events are called by the parent event. But when the parent event stops, the nested events are still playing, which is not desirable ingame.
Is there a way (other than code) to tell the nested events to stops when their parent is stopping ?

[Alcibiade]

Nested events are usually stopped when parent event is stopped. You may have set something a way I can’t figure… Can you tell more or share screenshots?

[g.hadji]

Hi. Thanks for your response. Here are three screenshots. One for the parent event and two for the nested events. I also tested it in the sandbox. When I play the parent event, everything works fine, but if I stop it, the biome event keeps playing.

[Alcibiade]

Yeah, ok, it’s what I thought first (the first message I finally removed): you’re using command instruments instead of normal nested events. Why do you do so? For routing consideration?
However, even so, it’s possible to stop a secondary event (it’s not really a “nested” event, in this case), by using another command instrument, linked to the main event state (see picture below).
However, note that the main event instance, while not producing sound anymore, seems to stay alive (pending stopping state) until the timeline doesn’t contain anything, which can cause unwanted effects. @joseph I’m not sure if that’s a bug or not. In my exemple, the main event will stay alive until Maker A. If there’s a loop, it can even stay alive indefinitely.

[g.hadji]

Hi and thank you so much for your response.The reason why I was using command instrument is not very logical. I am new to fmod and I have some Wwise old habits where it is very easy and straightfoward to use similar object as fmod command instrument to call events actions from another events. So I simply tried using nested isntruments as it is intended by fmod, and this time it worked. I also tried your command instrument method for the seek of knowledge and it worked as well. Thank you for letting me know about this cool feature !
The somewhat dumb conclusion of my post is that, after testing the event for a while, I tried to switch the biomeId parameter really fast (because this situation could happen in-game), and even after fancy ahdsr adjustments, it sounded really bad and stuttery. So I think about trying to use a system where instead of having only one event playing at a time, I would have both of them playing at the same time and I would use a continuous parameter with a seek speed value, connected to the events’s volume to have a smoother transition between them.

[Alcibiade]

@g.hadji

So I think about trying to use a system where instead of having only one event playing at a time, I would have both of them playing at the same time and I would use a continuous parameter with a seek speed value, connected to the events’s volume to have a smoother transition between them.

Yes, that could be better. Did you manage to find how to do that or would you like some advice? After a switch, would you ideally prefer to start at the beginning of audio items, or you don’t mind?

@g.hadji

this method prevent me from using the “biome A” and “biome B” sounds within the same event, because if the biome parameter is changing while we are in a timeline transition, fmod has to wait the end of the transition to then go to the other biome’s loop, and it could create weird non reactive sounding situations ingame.

That’s true but I’m a bit surprised it’s a problem here. How did you set your multis and the loops? How long are the audio items and the loop transition timeline?

[g.hadji]

@Alcibiade

That’s true but I’m a bit surprised it’s a problem here. How did you set your multis and the loops? How long are the audio items and the loop transition timeline?

My audio items are pretty short (about 1.5 seconds) and my transition timeline are about 1/7th of my items. I’m using the default fadein/out because it works well with this example. The multis are set with the default settings. In most cases this is not a problem but there’s a small probability of the parameter switching during a transition timeline, causing a delayed transition from the player’s point of vue.

@Alcibiade

Yes, that could be better. Did you manage to find how to do that or would you like some advice? After a switch, would you ideally prefer to start at the beginning of audio items, or you don’t mind?

I don’t really mind where the audio starts after a switch, as long as the transition run smoothly. I managed to do it by myself and it sounds ok. The only conserns I have with this methods is the memory cost of having so much voices running at the same time. In fmod, does the silent audio items becomes automatically virtual ? In this case, I guess this wouldn’t be a problem at all, what do you think?

[Alcibiade]

@g.hadji

In most cases this is not a problem but there’s a small probability of the parameter switching during a transition timeline, causing a delayed transition from the player’s point of vue.

That should not be the case, since your loops with transition timelines are in the nested events. I think you may have missed a few settings that would have make things work like you want with the AHDSR method. You should set a release (and maybe an attack) in the AHDSR on the master track volume of your children events, here [edit, it could also be on the nested event volume knob, in the parent event]:

Then your parent event, instead of a timeline sheet, could rather be a parameter sheet, and look like this (don’t forget to empy or remove the timeline sheet):

Though less elegant, it could also be a timeline sheet, of course. By the way, instead of using markers+loop+transition regions, you could compact to magnet regions, like this:

I just found what seem to be a big bug, which may have confused you, where nested events never stop while being untriggered. I will document it in another thread. However, when the AHDSR is set in the right place (which I guess you did incorrectly), the bug doesn’t occur.

@g.hadji

The only conserns I have with this methods is the memory cost of having so much voices running at the same time. In fmod, does the silent audio items becomes automatically virtual ? In this case, I guess this wouldn’t be a problem at all, what do you think?

Yes, there’s an initflag called FMOD_INIT_VOL0_BECOMES_VIRTUAL which does the trick. I don’t know if it’s activated by default. However, I guess it doesn’t change anything on memory cost (it’s only CPU).

The main difference between the AHDSR and the volume automation method will depend of the behavior you want in the case of a fast double switch: exemple, fast switch from A to B to A, do you want to come back to A almost at the place you just quit? Or it doesn’t matter if A restarts? In the first case, volume automation, in the second, AHDSR.

For the record I used FMOD Studio 2.02.00.

[g.hadji]

@Alcibiade

That should not be the case, since your loops with transition timelines are in the nested events.

Indeed the transition timeline issue I made refference earlier was appearing when I was trying to have my multis within the same event but on different markers without using nested event. The nested events solved this particular problem.

@Alcibiade

I think you may have missed a few settings that would have make things work like you want with the AHDSR method. You should set a release (and maybe an attack) in the AHDSR on the master track volume of your children events, here:

Actually, I did everything correctly setting the ahdsr (on master tracks with attack and release). And it worked, as long as I was not switching the biomeId parameter to fast. Otherwise I would need to set the max instance of my nested event to 2 instead of 1, to avoid any brutal cut from the stealing feature. Even so, te ahdsr method was making the event sounds less reactive and less smoother than the volume automation methods, even after doing a lot of tweaking with the envelopes.
However, thank you for your tips on how to optimize an ahdsr based event with parameter sheets or magnet regions !

@Alcibiade

Yes, there’s an initflag called FMOD_INIT_VOL0_BECOMES_VIRTUAL which does the trick. I don’t know if it’s activated by default. However, I guess it doesn’t change anything on memory cost (it’s only CPU).

Thanks I got to give it a try !

@Alcibiade

do you want to come back to A almost at the place you just quit? Or it doesn’t matter if A restarts? In the first case, volume automation, in the second, AHDSR.

I guess that in the end, the volume automation method is corresponding more to what I had in mind in term of fast switching behaviour.

[Alcibiade]

@g.hadji

Otherwise I would need to set the max instance of my nested event to 2 instead of 1, to avoid any brutal cut from the stealing feature.

Yes, I already raised this point and made a suggestion for steal release time, here:

Suggestion: steal release time

In fact, after thinking twice, I don’t really get the argument. I’ll explain myself. If stealing is a tool for resource management but always makes a pop by abruptly cutting the sound, then sound designers will mostly avoid to use it, but rather use it as a safety net (ideally never triggering). Eventually, why not leave the trade off to the sound designer, between an instant and hard steal, or a delayed, smoothed steal (with a temporary stealing voice count overload)? It would greatly expand …

However, in your case, I don’t think you should have set a max poly. You let the release cut the sound, even if it stacks with previous entries.

@g.hadji

I guess that in the end, the volume automation method is corresponding more to what I had in mind in term of fast switching behaviour.

That’s good, then!