AudioSound Finished Event

Scripting Issues
1

Hello,

Does anyone know why the finished_event stuff has been deprecated in the latest version of FMOD AudioSound, and, more specifically, whether or not there is still a way to tell when a sound has finished playing? I was using this functionality in something I wrote, and I’d like to still be able to know this.

Thanks,
Aaron

2

You could use taskMgr.doMethodLater(delayTime, myFunction, ‘Task Name’) if you set delayTime to the duration of the sound.

3

Thanks for the idea, but the problem is that I am allowing the user to pause and resume the sound at runtime - so I need to know when the sound has finished playing taking that into account, not just to know when the time of the length of the sound has passed…

4

If your user pauses audio, then you’ll know that the audio file isn’t playing anymore…
No need to check anything for this.

5

Maybe I’m not being clear; here is my full usage case:

There is a sound playing. My user has the ability to arbitrarily pause this sound and to arbitrarily resume play (which will pick up where the sound left off). I need to know when the sound itself has finished playing (taking any number of pauses and resumes into account). In an older version of AudioSound, sounds threw an event when they concluded playing (by reaching their end), which I was accepting (using getFinishedEvent()) and responding to. The new version says that the getFinishedEvent(), setFinishedEvent(), and finished() functions are not used anymore, so I no longer have a way of knowing that a sound has played through to completion (which is fundamentally different from being paused). I am wondering why these functions have been deprecated and whether or not there is anything else I can check on to learn this information.

Thanks,
Aaron

6

Okay, first of all you still could use the events generated when a user pauses the sound itself to stop the counter, that counts down the time the sound would play.
Resuming the sound will then also need to resume that counter.

Anyway, you can find out about the total length and the current playtime of a sound…

mySound.length()

returns the length of a sound in seconds.

mySound.getTime()

returns the the current time the ‘playback head’ of a sound is at in seconds.

So when you start a sound you have to put its length into a variable, then create a task that checks for the current time and compares it to the total length of the sound. Once the current playtime equals the length, you know that the sound has played to the end.

7

Thank you for the suggestion Legion; that looks like it would solve the problem, although we’re hoping to find a solution that works through the AudioSound module instead of operating with the task manager. Another solution would be to pull in intervals and then pair AudioSound objects with corresponding Seq(Wait(mySound.length()),Func(messenger.send,“Sound completed”)) intervals.

I think the question atarnow is asking is less how to work around the new design and more if there is a way under the new design to work with it as we previously did. The way the system was previously set up (as of Panda3D 1.2.3), AudioSound objects gave us all the information we needed to know when they started (i.e. when we told them to) and when they stopped (i.e. when they sent their termination message). The current design at the head of the repository requires us to use an external mechanism (such as creating a parallel timer or a monitor task) if we want to know when a sound stops. I think he’s primarily asking if there is a new way that we aren’t aware of to get the information directly from the sound object (as we used to) instead of creating our own duration-event objects by lashing two objects together.

As for me, I’m wondering from an architectural standpoint why the design of this portion of the Panda engine was changed—did it interfere with another portion of the engine, was there a design philosophy it didn’t match up with, or was a better way devised to do what it did? I’m assuming it wasn’t just changed to force us to re-write all our sound handlers. :wink:

Take care,
Mark

8

I think the change had to do with who rewrote the new FMODEx wrappers. I have been less than satisfied with this new version for a number of reasons. Sometimes I’m surprised it even seems to work as well as it does, given what I’ve seen in the code. It doesn’t look like a lot of attention was paid to smaller features and edge cases. While I would like to see this fixed, in the meantime I’ve done two things:

  • renamed the new FMOD wrappers “fmodex” and resurrected the older, better written FMOD3 wrappers as “fmod”
  • Written new OpenAL wrappers which are no only free, but are also carefully based on the miles wrappers which are the only ones that were written by disney so they support all of those more obscure features (like finished_event).

I’ve got got 2 bugs I know about, one with “distance” of 3d sounds and one with a number of sounds limit (32) to work out and then I’ll be posting all of this. I was also waiting for 1.4 to come out because I knew the release cycle had begun. I’m hoping to get this rolled into the next version. Meantime, I’ve been using it just fine as a drop in, no recompiling of panda, replacement. What version of Panda are you guys using and maybe I can get you a matching version.

9

You’ve implemented the finished_event with OpenAL? Or do you work around it with your own timer?

10

This is the reason I just created the forum for announcing work in progress… I’ve got two of you both working on the same thing. We should try to avoid duplication of effort like that in the future, we just don’t have enough developers.