proposal: Another set of renames about flutter_soloud HOT 4 CLOSED

Ok, I'll rename SoundProps to AudioSource but I won't touch the other classes. I agree we should keep voice separate (a subgroup?) of handles.

Thanks for looking into deinit()!

from flutter_soloud.

Possibly SoundHandle should be Voice? Although even the C++ docs are inconsistent and call it mostly "sound handle".

from flutter_soloud.

cc @alnitak for you thoughts on this

from flutter_soloud.

Or maybe deinit() should be a synchronous "kill switch"

I just came across this situation with #54 ! :) So I also think your deinit() "kill switch" is a good idea.

For example, SoundProps might become AudioSource.

IIRC I named SoundProps (SoundProperties shortened), to store the ways to manage it in native code.
Into SoundProps we could add for example the audio file name, like in native, but also any other properties we like. It's not really like Soloud::AudioSource which in SoundProps could be represented by SoundHash.
Anyway, I like AudioSource name more than SoundProps!

Possibly SoundHandle should be Voice? Although even the C++ docs are inconsistent and call it mostly "sound handle".

I recall that I get a bit confused too when I read voice. Maybe it's a deeper Soloud lib concept needed maybe if/when we will go deeper integrating the lib into the plugin. The Soloud author says "The handle is an integer, and internally tracks the voice and sound id, as well as an "uniqueness" value.", so I think the "voice" could be thought as a sub-type of a handle.

from flutter_soloud.