Hi!
We’re using Fmod 2.01.11 at the moment (paired with Unity).
In your documentation, it says “An event is considered oneshot if it is guaranteed to terminate without intervention in bounded time after being started.”
And yet we’ve encountered a few confusing examples of this not holding true.
First, we have an event containing a few instruments one of which has the “loop instrument” function switched on. We want audio inside this single instrument to have a randomized “start offset” and to loop whenever it starts from the audio’s end. The single instrument itself has a fixed duration, there’s no loop region or any other logic marker. The event as a whole ends on its own in bounded time without intervention.
Second, we have an event with a timeline containing a snapshot instrument. Again this snapshot has a fixed duration, no logic markers present, event ends on its own.
Both of these events when viewed in the Unity - Fmod Event Browser show as their status: Oneshot False
Their status changes to Oneshot True only once we get rid of the loop instrument in one event and the snapshot instrument in the other. Are we missing something? Should we be using the instruments differently? We don’t get how these events don’t match the above-mentioned oneshot event definition.
We wouldn’t have noticed this behaviour if it wasn’t for an issue it raised (strangely only after updating to newer version of Fmod). When our programmer calls one of these Oneshot False events more times a second. Several instances used to play on top of each other, now they keep cutting each other off. How should we approach this to avoid future issues? We want these events to contain snapshots and looping instruments while behaving as oneshot.
It’s a bit hard to briefly define a one-shot event, but essentially it means an event you can press play on and it will naturally stop by itself. There are certain objects within an event that will trigger the isOneShot flag. Objects such as:
Looping instruments on parameter sheets or action sheets
Snapshot instruments
Any loop regions, magnet regions, transition markers, or sustain points
The reason a snapshot instrument causes it to become non-oneshot is because a snapshot itself is not oneshot (it has no natural end). Unfortunately there isn’t a workaround to making these events oneshot, but you could create a function that checks the timeline position for a time you know it “ends” and automatically stop the event then.
For the snapshot event, I guess a workaround would be to start and stop the snapshot by using command instruments.
But if the parent event stops to trigger the snapshot at some point, it will always stop ; shouldn’t fmod analyse this that way?
Not sure, but I think he is talking about looping instruments on a timeline, with the instrument untriggered at some point. Can you confirm, @Electromess?
@Alcibiade is correct. It’s a single instrument, lasting 0.5 seconds on a timeline, its “loop instrument” checkbox is checked. After approx. 0.5 seconds cursor untriggers this instrument and the event as a whole stops on its own.
I believe the criteria for how a oneshot event is determined hasn’t been looked into for a while and it’s possible that some features might not properly fit into what an expected oneshot event should be. I’ve raised this as an issue to look into by our development team for a future version of FMOD Studio.
In the meantime, you could use the User Properties to manually set the events you know are oneshot, and then use EventDescription::getUserProperty to determine if an event is oneshot or not.
I don’t use Unity at the moment so I’m not aware of how the oneshot status appears. However, I did found in FMOD Studio a behavior that seems to be related to that oneshot status, though not documented anywhere: how untriggered nested events react (with “cut” unchecked). If it’s oneshot, it continues to play until the end of its content ; if it’s not oneshot, it stops when untriggered (for obvious reasons of avoiding infinite loop).
I did test that way @Electromess’s exemples and they do behave correctly. I’m a bit surprised that this hidden oneshot status doesn’t seem to match the official oneshot status reported by the API.
We’re in a similar situation. We moved from 2.01.09 to 2.01.11 and a bunch of behaviour that relied upon the One Shot status of an event broke.
Have there been any updates on this?
If I understand correctly, it appears the definition of a one shot changed in 2.01.11. (Maybe in order to improve “performance of repeated calls to […] Studio::EventDescription::isOneShot” as per update notes?)
It seems like the rationale for snapshots disqualifying an event from being a oneshot isn’t correct. While snapshots themselves aren’t bounded, a snapshot reference on a timeline is bounded by its clip length AFAICT. It seems to apply the override or blend only for the duration of the clip - unless there’s some mechanism for side-effects coming out of snapshots that I am unaware of.
In either case, it would be helpful to know if there’s planned support for broad mixing changes during a one-shot.
For now, I’m going to use the above suggestion as a temporary solution and try to figure out a way to automatically migrate old events events that would have been one-shots in the previous versions.
Revising the conditions for if an event description returns it as a one shot will require a bit more time to take into consideration everything new added since the last time it was visited. I can’t say for certain, but it could be possible that since snapshots themselves operate like a persistent event it was unintentionally propagating this property up to the parent event. We will take a look into this for a future update, but in the meantime the previously mentioned workaround is going to be your best solution.
