Changing volume of frame-linked audio

[Laura Hunt]

Hey all.

I have a sound (e.g., aSound) that I want to use in two different animations, triggering it from a specific frame. From what I gather, the volume this sound will play at when it's triggered will be the DefaultVolume value I've set in the audio clip's Properties panel.

My problem is that when animation 1 runs, there is very little background noise, so aSound is perfectly audible, but when animation 2 runs, there is music and other stuff playing, so aSound kind of gets lost in the background and I would need to increase its volume a bit.

My question is: is there a way to change the volume of a frame-linked audio clip when it's triggered, or would my only solution be to create two copies of aSound, each with its own DefaultVolume?

In other words, is it possible to modify an audio clip's DefaultVolume property from script?


Edit: I also know I could work around this by creating an audiochannel on the fly and doing something like this, but if there's a less convoluted way, of course I'd love to hear about it:

Code: ags

oMyObject.Animate(0, 6, eOnce, eNoBlock);  // make the animation non-blocking so I can insert stuff while it's running
while (oMyObject.Frame < 15) Wait (1);  // frame in which I want the sound to trigger
Audiochannel *tempsound = aSound.Play(eAudioPriorityNormal, eOnce);
tempsound.Volume = 40;
while (oMyObject.Frame < 30) Wait (1); // last frame of the animation

[Laura Hunt]

* pokes thread with a stick * Hello? Is this thing on?

[Cassiebsg]

It's on, and I don't know... but that seems like perfectly fine code, not too " convoluted" at all...

[morganw]

Yes, I think the alternative is to not use use the frame->audio link, which would likely end up with you doing something similar on a grander scale. I guess the risk in either case is that there is not a free channel and you accidentally adjust the volume of the wrong sounds, so maybe a higher priority is safer, as well as checking if the channel reference is null before operating on it. So as long the blocking behaviour is OK for you, the approach you've taken is probably more straightforward then any alternative that springs to mind. Maybe someone else knows better though...

[Laura Hunt]

It's on, and I don't know... but that seems like perfectly fine code, not too " convoluted" at all...

Hmph yeah, it's pretty straightforward, and I guess I could even make it a function in order to save typing. For now, I've just created copies of the audio clips that need to be played at two different volumes; it's easier to adjust the volume directly from the Properties panel than searching through my code to see where I triggered it.

Mostly, I'm curious about how there are properties that can only be accessed through the editor but not through script, or if they are, they are read-only. As a non-programmer, my intuition is that, if something can be set in the editor, it should be avaliable in-script too. But I guess there are technical reasons to keep some stuff like this?

[Laura Hunt]

Yes, I think the alternative is to not use use the frame->audio link, which would likely end up with you doing something similar on a grander scale. I guess the risk in either case is that there is not a free channel and you accidentally adjust the volume of the wrong sounds, so maybe a higher priority is safer, as well as checking if the channel reference is null before operating on it.

Hm true, I'm usually very careful with my audio channel assignments and I always know everything that's going on audio-wise at any point, but despite this I've sometimes had nasty NPEs pop up on me because a sound didn't play because all channels were occupied, and a .Volume call crashed the game. Something to look out for indeed!

So as long the blocking behaviour is OK for you, the approach you've taken is probably more straightforward then any alternative that springs to mind. Maybe someone else knows better though...

Yes, this approach only works if you want the animations to be blocking. For non-blocking animations, I would definitely have to frame-link the audio and use the alternative option of making copies of the sound clips at different DefaultVolume values.

Thanks for your input! Hope this thread will be useful for anybody in the future with this exact same problem

[morganw]

I've just created copies of the audio clips that need to be played at two different volumes

To be honest, I think I would do the same, just to remove the extra complication in the scripting.
Probably by applying some extra processing on the source and convincing myself that it sounds better than simply turning the volume down

Mostly, I'm curious about how there are properties that can only be accessed through the editor but not through script, or if they are, they are read-only. As a non-programmer, my intuition is that, if something can be set in the editor, it should be avaliable in-script too. But I guess there are technical reasons to keep some stuff like this?

I think there are still some properties which aren't exposed to the editor, but in cases like this it is normally that the game engine had some hard coded behaviour to take some shortcuts or apply specific operations on your behalf (rather than a discrete property), but there is no return path for any references to be passed back to you to take further actions on. The options to lookup what happened retrospectively aren't great either, you would probably have to poll all channels to see which clip they are playing and try to work out if one of these is your new one.

[Laura Hunt]

I've just created copies of the audio clips that need to be played at two different volumes

To be honest, I think I would do the same, just to remove the extra complication in the scripting.
Probably by applying some extra processing on the source and convincing myself that it sounds better than simply turning the volume down

lol, to each their own, I guess

Mostly, I'm curious about how there are properties that can only be accessed through the editor but not through script, or if they are, they are read-only. As a non-programmer, my intuition is that, if something can be set in the editor, it should be avaliable in-script too. But I guess there are technical reasons to keep some stuff like this?

I think there are still some properties which aren't exposed to the editor, but in cases like this it is normally that the game engine had some hard coded behaviour to take some shortcuts or apply specific operations on your behalf (rather than a discrete property), but there is no return path for any references to be passed back to you to take further actions on. The options to lookup what happened retrospectively aren't great either, you would probably have to poll all channels to see which clip they are playing and try to work out if one of these is your new one.

I see. Well, happy I found a way around it at least