You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alternatively, if we could pass a closure to set_volume() of the form |cur_vol: Volume| calculate_new_volume(cur_vol), that would cover the most notable usecase(s).
I've discussed this a bit in the Bevy discord, but there's some considerations for a feature like this:
Which volume do we report - the actual volume as last reported from the audio thread, or the one last set by the user? (Or both?)
If it's the former, I'd want to make sure this doesn't have significant performance impacts
If it's the latter, it's worth keeping in mind that the last-set volume won't always be a number. It could be Value::FromModulator, in which case, you wouldn't just be able to increment or decrement that value.
Do we even need this function? You can track the last-set value yourself, although you can't track the current volume unless the audio thread reports it.
I don't want to add this unless the pros outweigh the cons (performance, potential disappointment/confusion when people realize they can't rely on get_volume returning a number). The pros seem minimal to me currently, and I have no idea what the cons are.
get_volume()
would get the volume as set byset_volume()
.Other audio libraries seem to have this in their API:
https://www.fmod.com/docs/2.00/api/studio-api-eventinstance.html#studio_eventinstance_getvolume
https://docs.rs/rodio/latest/rodio/struct.Sink.html#method.volume
And it could be helpful in situations where the volume is set from different places.
The text was updated successfully, but these errors were encountered: