Can't figure this one out

if self.ActorAct == "atk":
    PulCrFrm = self.Actor.getCurrentFrame();
        if PulCrFrm == 0 or PulCrFrm == 60 or PulCrFrm == 120 or PulCrFrm == 180 or PulCrFrm == 420 or PulCrFrm == 480 or PulCrFrm == 540 or PulCrFrm == 700:

            if self.Swd_Swing1.status() != self.Swd_Swing1.PLAYING:

            if self.Swd_Swing1b.status() != self.Swd_Swing1b.PLAYING:

This should be simple but yet it’s not. I’m trying to get the sounds to play at specific frames as you can see.

The sounds do not play at all the frames; maybe a couple of frames and that’s it.

I’m guessing the speed at which the frames are cycled though is causing the problem. It also seems like sounds stall for a second or two before playing.

Is there anyway to get 3D sounds to play “on Q” at certain frames of animation?

If someone could solve this one, I would be impressed, because I don’t think there’s a solution.

check out ActorInterval, perhaps?

It looks like it’s related to animation speed, as in the call for the sound can’t keep up, but I believe it’s a buffer issue more than anything.

I’ve worked with engines in the past that lets you set a number of buffers for a sound, so in this case, the same sound would play again even if it’s already playing.

I’m guessing OpenAL doesn’t support this. If that’s the case, then it’s going to be hard getting a more natural usage of sounds using P3D.

When checking to see if sound is playing, the number 2 is being returned.

That’s not exactly true and false (1/0).

Does anyone know what the number 2 stands for?

This is an update:

What I did, since sounds don’t seem to have buffers (but this may not be the cause), is break down my animation. Instead of having the whole animation play though in one call,

I play each part of it separately. That way I can have greater control over when the sounds actually played. The issue could have been animation frame rate being too fast. It’s just, the code runs in every step of the app, so you would expect every appointed frame to be caught. Guess not.

Anyway, I have things working a whole lot better now. I’m still trying to tweak it a bit because now I have a sound playing so quickly, it almost beats the start of the animation, but that’s with one particular part.

As good as it’s going to get I guess.

Are you talking about sound.getStatus()? This will return one of AudioSound.BAD, AudioSound.READY, or AudioSound.PLAYING. As it happens, AudioSound.PLAYING == 2, but you’re not supposed to write “2” in your code, use AudioSound.PLAYING instead. And that’s what you’ve done in the clip above.

Your logic has a problem, though. You check for specific frames being reached exactly. It’s possible, if your frame rate is not perfect, that your animation will skip over any one of those frames and you’ll never see it. But if you use an Interval to control the playing of sounds, you won’t skip over anything–this is the purpose that an Interval was designed for.


No no, Lol! I was checking the status of sound.PLAYING like,

print str(sound.PLAYING)

I saw the 2 returned and wasn’t sure what it meant, since I’m so use to seeing true and false. I think I solved the problem by breaking down the animation.

I guess you can’t really play a long animation and expect to play a sound on certain frames while the animation is playing out, but if you break that animation down into several pieces, the sound will play everytime you start the next section of the animation.

Intervals have given me problems, especially animation ones, so I don’t use them. I don’t feel I have full control with animation intervals, because I had problems getting them to stop flat when I needed them to. So anything that deals with intervals, I try to avoid.

May I ask, Drwr, are you solely working on updating P3D or is there several of you under staff? I know the community helps out too. Just wondering how many original P3D makers are still active on it.

Might as well throw this in -
Is there a way to tell a sound to wait for so many seconds then play (without intervals)? I’m guessing no.

sound.PLAYING is a constant value. It is always 2. The point is that it is the value that sound.getStatus() will return when the sound is playing.

I’m sorry that intervals have given you problems, but I assure you they work well (for what they’re supposed to do), and that this would be a fine use for them. When you’re ready to embrace them, I’m sure you’ll be able to make them work for you. :slight_smile:

I am a Disney employee, and I am one of the original designers and developers of Panda3D. Disney no longer has as much budget for Panda3D development as it used to, and I am not as active in Panda3D as I once was. There is no staff. We have to rely on the community more nowadays. But I still keep a toe in the water, and I still maintain a presence on these forums.

You can always use a task to control precise timing sequences. Or you can simply design a soundfile which has a certain number of seconds of silence at its beginning. Or, you can use intervals. :slight_smile:


The only thing I need to know now is how to correctly clean up the audioManager and sounds.

Not sure how to get all sounds garbage collected correctly.

Secondly, is it better to use one audioManager or multi audioManagers? I am giving Actors their own sound, but I currently plan on using one audioManager for all 3D sounds.

I would drop dead if I see memory constantly rising because incorrectly cleaning up sounds during an Actor destroy caused data to get trapped in memory.


I think I’ve come up with a logical solution to avoiding small memory leaks when defining sounds.

I ran a test to confirm that sounds are not dumped from memory easily.

del self.Swd_Swing1;

I ran my old auto create and destroy test again. I sat and watched memory slowly, but for surely increase and it did not stop. That’s with sound defined within the instances.

I then removed the sounds defined within the instances and ran my auto create and destroy test again. My app’s memory was sitting still again and not increasing without bound.

No surprise. I didn’t expect Python to clean out OpenAL’s audio manager. You would think OpenAL APIs or OpenAL API bindings would be used for that.


Because I know a game will have to be reset, and resources will have to be dumped as players are brought back to the title screen…

I am going to define all my sounds within my AudioClass. I can then attach sounds defined within the AudioClass to the correct instances by creating some methods. I can then just detach the 3D sound from the instance and destroy the instance as usual.

If a player were to reset the game, the AudioClass would not have to get destroyed, because the same sounds are going to be used again, so why try to dump the resources? Right? Right on! Lol.

I’ve been fooling around with Panda’s sound all day and have grown tired, but first thing tomorrow, I’m going to place all defined sounds inside my AudioClass and create some methods to attach and detach those sounds to objects.

Then I’ll run my auto create and destroy test again and see how the cookie crumbles. Hopefully, it’s a sturdy cookie.

Phew! I am beat!

I noticed something when creating an instance of an object class that’s going to define things that will need to destroy later, and that is defining under base. That’s were memory leaks for me occur. This happened back when I was trying to give every instance it’s own Collision Trav.

I solved that problem by simply giving the App one collision trav class.

The same thing is happening when defining 3D sound, or more exclusively, base.sfxManagerList[0]. defining anything under base exclusively within an instance seems to cause memory leaks.

What I did to get pass this ordeal, was define sound as:

self.MM1_Swing1 = loader.loadSfx(GameDIR+"sndfx/wep/swd_swing1.wav");

The manual shows it as base.loader.loadSfx. No no…can’t go there, not with base.

What I did next was write my own code that turned sounds into 3D sounds. So now I’m getting the same 3D effect the 3D audioManager provided, but without the memory leak because I can truly destroy the sounds defined within the instance cleanly.

Took me the whole day to come to this conclusion. Lol. It works for me at no fps cost, so I’m sticking with it.