Expanding the /sound API - Fade out

ID:2894305
 
Oct 19 2023, 3:56 pm
Applies to:Dream Seeker
Status: Open
Issue hasn't been assigned a status value.
It would be cool if we could send a SOUND_UPDATE to fade sounds out, since I looking to work on an ambience feature that switches between multiple sound tracks depending on the situation of the player, but I'm unable to do this seamlessly without being able to fade sounds out.

Adding a way to fade currently playing sounds on a channel would make my life a lot easier since I wouldn't have to look for hacky workarounds for what should be a simple effect.

It would also be cool if the sound API got more love in general, the things you can do with sound in byond is really limited and it's a shame since sound design is a big part of the immersive experience of playing a game.
Oct 19 2023, 10:54 pm
This is already possible.

client
    var
        music_on        = 1
        music_volume    = 100
        sfx_volume      = 1

        sound/current_song  = null
        volume_multiplier   = 1



    proc





        play_song(sfile, do_repeat = 1, _volume = 0.6)
            /* called to make [sfile] the playing song
            */
            if(sfile != current_song) // if the ambiance track isn't the one being played already, make it so!
                var/sound/S         = sound(sfile)
                S.environment       = -1
                S.repeat            = do_repeat
                S.channel           = 16
                S.volume            = 100*_volume
                volume_multiplier   = _volume
                current_song        = S
                if(music_on)    src << current_song
                else            src << sound(null, repeat = do_repeat, channel = 16)



        adjust_music_volume(adjust)
            /* called to adjust the volume of a currently playing track.
            */
            music_volume += adjust
            if(music_volume < 0) music_volume = 0
            else if(music_volume > 100) music_volume = 100
            if(current_song)
                current_song.volume = volume_multiplier * music_volume
                current_song.status = SOUND_UPDATE
                src << current_song


Pardon the unrelated fluff, but this is how I handle adjusting volume in real time. You just need to make sure you're logging the currently playing sound definition in a var.

To make use of the proc and fade volume in or out, you can do something like this:

            for(var/i = 100, i, i-=2)
                adjust_music_volume(2)
                if(current_song.volume == 0) break
                sleep 2


This would be an example of fading the currently playing song out.
Oct 19 2023, 11:31 pm
For obvious reasons, that solution is not optimized in the slightest and is a hacky workaround for the inability to manipulate a sound after it's been played during playback without awkward channel nonsense.
Oct 20 2023, 12:39 am
In response to Iamgoofball
I'm not sure what you mean. It's fairly lightweight and straightforward. You can even simplify it a lot further.


hacky workaround for the inability to manipulate a sound after it's been played during playback without awkward channel nonsense.

I'm not sure how else you would accomplish what you're requesting, though. I definitely agree that updated and improved sound features would be nice, but are you suggesting we get a new /sound.status flag for SOUND_FADEOUT/SOUND_FADEIN?

I feel like this would be unnecessary and remove a lot of the granular control you get by just accomplishing the effect you're after with the available means.

What is it about having to manually set up a volume fader that is non-viable for you? The way you're speaking suggests it isn't possible or has serious performance faults, but to my experience, neither of these points are accurate.


I guess my main question is how exactly would you want a native fade in/out implementation to work that it would be easier than the current implementation?


Oct 20 2023, 1:02 pm (Edited on Oct 20 2023, 1:10 pm)
The fact that it's handled serverside instead of clientside.
If the serverside has to send updates to the client to adjust their volume, if the data is not received in sequential order with consistent timings, it will not fade out smoothly and it will be extremely jarring.

Being able to "animate" it on the client will guarantee smoothness, so a flag would be preferable.

Having a flag does not remove granular control. If you want to accomplish it on the serverside, you would still be able to. But it has performance problems, clientside ones. Sound design has to be consistent and non-jarring or else it will sound incredibly bad and that's why a clientside variant would be preferable.

If it's not possible, I'm just going to have to resort to using the browser because there is clientside control in using a browser to play and manipulate sounds, but it would be preferable if byond's sound API also offered its own version of this.

Having more options increases the amount of granular control you get by allowing you to weigh your options and use what you need to use. This would be especially useful to me because the games I work on have a lot of processing going on and the server cannot always allocate time to smoothly adjust volumes on every single player.

This wouldn't be a problem if I had the ability to do the same sort of code on the clientside, but the only way to do that is via browser which means I'd need to host my audio files on a CDN and it's even less granular than byond because it's stuck on internet explorer.
Oct 20 2023, 1:10 pm
Something like animate() for sound datums would likely be best.

Iamgoofball is correct though that manual fade out like the example given would be much more expensive than telling the client to do it. How much more I would need to profile, but I'd be worried about the impact of doing this for 100 players at once.
Oct 20 2023, 1:15 pm
This feature request would also be a viable solution for my feature request:
https://www.byond.com/forum/post/2839944