# Event Description - confusion around Oneshot Status **URL:** \ **Category:** FMOD Engine\ **Tags:** unity\ **Created:** [October 25, 2021, 12:12pm UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843 "2021-10-25T12:12:31Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Electromess](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/electromess/32/2794_2.png) [@Electromess](https://qa.fmod.com/u/Electromess)\ **Post date:** [October 25, 2021, 12:12pm UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/1 "2021-10-25T12:12:31Z")
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. ---
**Author:** ![Alcibiade](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/alcibiade/32/4284_2.png) [@Alcibiade](https://qa.fmod.com/u/Alcibiade)\ **Post date:** [October 25, 2021, 8:39pm UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/2 "2021-10-25T20:39:37Z")
Perhaps you checked “persistent: on” by mistake on both events? ![image](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/d/d33ed2a1aaa93743c2e7841feba02fd262d61755.png) ---
**Author:** ![Electromess](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/electromess/32/2794_2.png) [@Electromess](https://qa.fmod.com/u/Electromess)\ **Post date:** [October 26, 2021, 8:24am UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/3 "2021-10-26T08:24:49Z")
Thanks for the brisk response. Sadly that’s not it. Persistence stays greyed out. ![oneshot false event 01](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/0/0e5ed017f294adac7aa2d3a3f1f33f9c5a7e9a2e.jpeg) ![oneshot false event 02](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/5/52342f882a71c032fdb0e6a21ba241957b29bdf1.jpeg) ![oneshot false event 03](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/c/c5f801a89cdd27e8a6cf64111c8ce20312d26e95.jpeg) ![oneshot false event 04](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/e/e5e5ddba79a10ff7a11dae433c3899147a359024.jpeg) ---
**Author:** ![richard\_simms](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/richard_simms/32/261_2.png) [@richard\_simms](https://qa.fmod.com/u/richard_simms)\ **Post date:** [October 27, 2021, 4:22am UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/4 "2021-10-27T04:22:45Z")
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. ---
**Author:** ![Alcibiade](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/alcibiade/32/4284_2.png) [@Alcibiade](https://qa.fmod.com/u/Alcibiade)\ **Post date:** [October 27, 2021, 7:45am UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/5 "2021-10-27T07:45:52Z")
For the snapshot event, I guess a workaround would be to start and stop the snapshot by using command instruments. > [@richard\_simms](#): > > The reason a snapshot instrument causes it to become non-oneshot is because a snapshot itself is not oneshot (it has no natural end). But if the parent event stops to trigger the snapshot at some point, it will always stop ; shouldn’t fmod analyse this that way? > [@richard\_simms](#): > > Objects such as: > > - Looping instruments on parameter sheets or action sheets 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? ---
**Author:** ![Electromess](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/electromess/32/2794_2.png) [@Electromess](https://qa.fmod.com/u/Electromess)\ **Post date:** [October 27, 2021, 8:10am UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/6 "2021-10-27T08:10:43Z")
@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. ---
**Author:** ![richard\_simms](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/richard_simms/32/261_2.png) [@richard\_simms](https://qa.fmod.com/u/richard_simms)\ **Post date:** [October 28, 2021, 2:39pm UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/7 "2021-10-28T14:39:52Z")
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. ![image](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/0/083d45373e0a6338780289fa058d89b2329aa9fc.png) [https://www.fmod.com/resources/documentation-api?version=2.02&page=studio-api-eventdescription.html#studio\_eventdescription\_getuserproperty](https://www.fmod.com/resources/documentation-api?version=2.02&page=studio-api-eventdescription.html#studio_eventdescription_getuserproperty) ---
**Author:** ![Electromess](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/electromess/32/2794_2.png) [@Electromess](https://qa.fmod.com/u/Electromess)\ **Post date:** [October 29, 2021, 9:08am UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/8 "2021-10-29T09:08:36Z")
Got it. Thank you, guys! We will look into this as a temporary solution. 👍 ---
**Author:** ![Alcibiade](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/alcibiade/32/4284_2.png) [@Alcibiade](https://qa.fmod.com/u/Alcibiade)\ **Post date:** [October 29, 2021, 4:31pm UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/9 "2021-10-29T16:31:26Z")
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. ---
**Author:** ![tim-charmgames](https://avatars.discourse-cdn.com/v4/letter/t/22d042/32.png) [@tim-charmgames](https://qa.fmod.com/u/tim-charmgames)\ **Post date:** [December 9, 2021, 6:52pm UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/10 "2021-12-09T18:52:25Z")
Hello, 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. Thanks ---
**Author:** ![richard\_simms](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/richard_simms/32/261_2.png) [@richard\_simms](https://qa.fmod.com/u/richard_simms)\ **Post date:** [December 16, 2021, 12:00am UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/11 "2021-12-16T00:00:45Z")
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. ---
**Author:** ![Marbel](https://avatars.discourse-cdn.com/v4/letter/m/a88e4f/32.png) [@Marbel](https://qa.fmod.com/u/Marbel)\ **Post date:** [July 15, 2025, 2:45am UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/12 "2025-07-15T02:45:09Z")
I would just add scatterer instruments to this list. They also have no defined end and will remove oneshot status. ---
**Author:** ![joseph](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/joseph/32/264_2.png) [@joseph](https://qa.fmod.com/u/joseph)\ **Post date:** [July 17, 2025, 5:14am UTC](https://qa.fmod.com/t/event-description-confusion-around-oneshot-status/17843/13 "2025-07-17T05:14:52Z")
Scatterer instruments are similar to looping multi instruments: You’re right that they may continue indefinitely when they’re placed on non-timeline parameters; however, on the timeline, they are guaranteed to terminate in bounded time unless there are logic markers capable of keeping the instrument triggered or retriggering it.