Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: get_volume() for StaticSoundHandle and StreamingSoundHandle #92

Open
GitGhillie opened this issue May 2, 2024 · 2 comments

Comments

@GitGhillie
Copy link

GitGhillie commented May 2, 2024

get_volume() would get the volume as set by set_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.

@ItsDoot
Copy link

ItsDoot commented May 4, 2024

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).

@tesselode
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants