I was tracking down a bug as to why some of our events seemed to fade out properly while others did not.

I discovered that if I had a music event with max playbacks 1, if I started the event by calling:
mEventSystem->getEvent(eventFullPathAndName, FMOD_EVENT_DEFAULT, &event);

and later stopped the event by calling:
mEventSystem->getEvent(eventFullPathAndName, FMOD_EVENT_DEFAULT, &event);

that the event would not fade out.

If, however, I started it in the same way, but stopped it by calling stopAllEvents on the category containing the event, it faded out nicely.

Also, I found if I held onto the the FMOD::Event* on which I called start(), then called stop() on it later, the event also faded out nicely.

I suspect this is something to do with the second call to getEvent when the max playbacks is 1.

I suppose I was hoping the event would not be "stolen" when I have just fetched it and have yet to "do" anything to it.

It is nice to have our system accessing events through name, because it is tied to a very string-oriented scripting language for our game engine, so it is convenient for the sound designer to call script functions to start and stop events by name.

Is there someway I can get this to work with getEvent and the event name??

Thanks in advance.

  • You must to post comments

Each time you call mEventSystem->getEvent you’re requesting a new instance of an event from FMOD. You say your event has "Max playbacks" = 1 so your second call to mEventSystem->getEvent is actually stealing the instance returned to you by the first call. When an event instance is stolen it’s stopped immediately, hence the fadeout isn’t heard.

To fix the problem, don’t call mEventSystem->getEvent a second time – just use the event instance handle that FMOD returned from your first call to mEventSystem->getEvent, as this is the one you actually want to stop i.e. you want to stop the one you’ve got, not get a new one and stop that.

  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.