When triggering events on a parameter sheet, I frequently have problems with the sound getting re-triggered if the parameter is changed during the playback of the event, making the sound start over from start, causing multiple instances to play even if there’s only one actual trigger in the game.
Is there any way to work around this? I only want the sound to trigger by its actual in game trigger, if the parameter would change while the event is still running, I want nothing to happen. Is this possible?
You can prevent instruments from triggering multiple times in a parameter sheet by adjusting the instrument’s polyphony, which you can find under the instrument’s trigger behaviour. If you change the stealing mode from “Oldest” to “None”, and set the Polyphony to one, the instrument will not be able to be triggered again until the current instrument voice has stopped playing.
Thanks Louis! That’s very helpful. However, I still have the problem that the new instrument, that’s triggered by the change in parameter, will play. This fix prevents the first instrument from getting triggered again if the parameter would change back, but I still get that second sound triggered, which I don’t want. After the first instrument is triggered, I don’t want any other sounds to play, regardless of parameter change, in this instance of the event.
More context: I have short, non looping sounds divided into multiple instruments on a discrete parameter sheet, with one multi instrument for each value of the parameter. If the parameter change while the event is still playing, it will play that new instrument as well.
I suppose I have to set the event up differently, maybe with a nested event somehow. I’ll do some experimenting.
Edit: I tried setting it up as a nested event, setting its polyphony values to 1 with no stealing, but still same problem.
As one instrument cannot check when another instrument has stopped playing, what you’re trying to accomplish won’t be possible in a parameter sheet, but there’s still a couple of ways of doing it. To handle it purely in Studio, I’d recommend setting up your instruments on a timeline sheet, and using a logic point to control the flow of playback. A logic point is a single point on the timeline with one destination marker, and a one transition marker for each instrument on the timeline - each of the transition markers in the logic point uses a parameter value/range as a trigger condition. Your setup might look something like this:
The only thing to note about using a logic point as shown above is that the event’s playback will stop after transitioning to the logic point if none of the transition markers match the current parameter value - if needed, you’ll have to restart the event from your game. If you’d like playback of the event to continue indefinitely (without playing any audio) until the parameter is changed to a valid transition value, you can insert a loop region at the logic point, and replace the transition markers with transition regions:
You could also handle it from your game. You would track the equivalent of your event’s parameter ingame, and use that to handle playing the corresponding events. When the current event has finished playing, which you can check whether it has stopped with Studio::EventInstance::getPlaybackState, and then use the “parameter” value to play the next corresponding event.
Hi and thanks for the thorough answer! That is a possible set up, I’ll try that!
I’m a bit confused though, Maybe I have misunderstood the use of parameter sheets, as a way to trigger different sounds based on parameter data. Is that not their intended use? I’ve had similar cases with water splash sounds that should play different samples depending on object/player velocity on impact. With their longer tail, these also trigger a new sound if the parameter changes while the sound is playing and play another sound, creating extra splashes without any apparent trigger from the game. Would these cases have to be controlled via game code in that case?
I suppose I should add even more context to this specific case:
I’m using command instruments in the event playing the music of the game, to set a global parameter that defines what musical key is currently playing. That parameter is then used in various events to chose between sets of tonal sounds organised by musical key, to have them always match the music. In some songs I’ve added multiple command instruments, since the music changes key quite often. That parameter change causes the tonal events to play lots of extra sounds, without apparent trigger. It took me a long while to figure out why it happened!
However, I suppose setting it up the way you suggest with logic points is an easy workaround, I’ll give that a try!
If you set the Trigger Behaviour on the multi-instrument rather than on the event, you can prevent it playing multiple times when the parameter leaves the triggering area and returns again.
That should let you trigger new multi-instruments when the parameter reaches them, without re-triggering a multi-instrument that is currently already playing.
As for the splashing, that might be a game engine-side fix — if you use a local parameter rather than a global one, and only set the parameter on this particular event at the moment it is triggered, the parameter will not change after that (unless you send a parameter update to the event instance from the game engine), so that should avoid the multiple splashes problem.
The use of parameter sheets is as a way of triggering different sounds (or automation) based on parameter data, yes. The issue is that instruments cannot tell when other instruments have finished playing, which is why using a timeline or checking whether an event has stopped from code are better options if your desired behaviour is to finish playing a sound before being able to play another.
Handling it from you game engine is indeed one way of fixing the issue, but obviously requires that you essentially use the event as a one-shot - you’d need to check that it has stopped playback before restarting it.
It is possible to use your existing global parameter with this method, without having to set the local parameter from code every time you need to play the event, by doing the following:
Set up a local paramater that automates to the reflect value of your global parameter, but is set to hold on playback
From code, create, start and (optionally/when required) release your event instance
The event’s local parameter will update to reflect the global parameter’s value when you create the event instance, and then hold once you call EventInstance::start(), therefore not triggering any more instruments in the event.
Thank you for the answer! However, the problem is not that the same instrument triggers again, but that a new instrument is triggered as the parameter changes. I want the event to only play one sample once, when triggered via the game, and never what so ever trigger anything else based on only a change in the parameter.
I suppose Louis idea of doing it with logic points instead is a better option, will try that today.
Thank you Louis! I’ll try your logic point suggestion first, if it doesn’t work I’ll take a closer look at this. I thought this would be an easy set up, but it seems like it’s more complicated than I thought!
Well look at that, yes it does! Amazing. I knew there should be an easy solution to this. Thank you!
I just finished setting up a new event using logic points instead, which also worked. It got a lot more messy though, “hold value during playback” was exactly what I needed.
