I am trying to reconstruct a sound for a weapon in studio with a looping section followed by a tail and am having issues trying to get this to key off/stop correctly and play the tail. I’m trying to do this a couple different ways, using the loop regions and sustain points.
If I set it up with a looping region and call stop(FMOD_STUDIO_STOP_ALLOWFADEOUT) the sound terminates immediately.
If I set it up with a sustain point and call stop(FMOD_STUDIO_STOP_ALLOWFADEOUT) the call succeeds, the audio output terminates immediately but the event stays alive and will silently sustain at the sustain point. Even though stop succeeded, calling release() will still fail returning FMOD_ERR_EVENT_WONT_STOP
If the event is sustaining and I grab the first cue and trigger that when it is sustaining it will play the tail correctly, but the event state is always FMOD_STUDIO_PLAYBACK_PLAYING, and it can’t be released because it always returns FMOD_ERR_EVENT_WONT_STOP (even though it is well past the maximum timeline of the event) and it can’t be stopped without cutting off the tail because FMOD_STUDIO_STOP_ALLOWFADEOUT stops immediately and we have no way in code to know when the event should be stopped.
Is there an equivalent to the fade out time in studio? Because without that, FMOD_STUDIO_STOP_ALLOWFADEOUT has no meaning right now since there is no concept of fade out I can see. It would be useful to have a stop mode that just disabled looping regions and triggered sustain points and let the event ‘play through’.
When is FMOD_STUDIO_PLAYBACK_IDLE supposed to return?
In Summary:
FMOD_STUDIO_STOP_ALLOWFADEOUT is not functionally different than FMOD_STUDIO_STOP_IMMEDIATE except sometimes it doesn’t stop the event.
There is no way to release an event with a sustain point and safely hear all of it.
If I could make some suggestions about how events should stop:
Immediately - Used for when the game state has to make an abrupt change, e.g. the player teleported to a new area.
Fade Out - Internally just sets a fade timer and when the volume is 0 it stops the event immediately. This would be used for when the sound needs to terminate abnormally but for polish reasons fading out sounded better. E.g. A vehicle was racing and exploded. We would need to stop the engine and car sounds, and cutting them out immediately may be noticeable. Perhaps the fade out could be setup in the event macros section along with Polyphony and Priority, you could set the time and select a fade curve etc.
Play Through - Just disables loop regions and sustain points, and turns any event into a one shot. This would be useful for the gunshot example above.
After calling stop with any of these modes, they should be releasable.
That is a bug, I have fixed it for the next release. The logic for determining whether or not an event would stop was not taking into account looping instruments which would be cut off by the timeline.
Fades are implemented using the AHDSR modulators on the event volume in the event macros section, the ALLOWFADEOUT mode will wait for these modulators to complete. These are the replacement for fade in/out of designer, it will process the attack, hold, and decay, then it will sustain until stop is called.
The idle state indicates that the event is not playing any sound and wont play any more sound without user intervention (i.e. parameter change). On the other hand the stopped state indicates that it wont make any sound without start being called.
The first two points are the expected behavior with the current system. The third point is interesting, it makes sense in the context of a wind up/wind down type event, but for a more complex event which isn’t intended to follow the timeline linearly, it could sound very odd. You can achieve this behavior with sustain point based events by triggering the cue ahead of time. The cue triggers are ref counted, so if you trigger it N times it pass through the next N sustain points.
The AHDSR modulator method is pretty cool. Could this work on parameters too? I would imagine something like this could be applied to an RPM value for example, and just make sure parameters blend in and out of the game parameters nicely.
#3 could also be solved if we could release an event where the cues were triggered.
AHDSR modulators can be applied to (almost) any knob that appears in the deck. It’s therefore possible to apply AHDSR modulation to an event parameter by using an event sound module or an event reference module.
The trick is, though, that AHDSR modulator behavior is based on the triggering and untriggering of the module or track the modulation is applied to. You cannot modulate the behavior of an effect module property based on the triggering and untriggering of a multi-sound module, for instance, because effect modules can only be placed on tracks. If you want to do something like that, you’ll have to use event reference modules or automation, instead.