SoundRecorder functionality

[petoknm]

In C++ was able to create my own audio stream handler like this. I cannot find a way how to do this with the rust bindings. I need to be able to process data as it comes in not in bulk like with SoundBufferRecorder. Is there a way to extend the bindings to be able to do this?

[petoknm]

I can see the trait sfml::audio::SoundStream but I see no implementors...

[petoknm]

Also the SoundStreamPlayer seems to be useless without any SoundStreams... even the example for it is missing the MusicStream

let mut music_stream = MusicStream::load("cool_song.ogg");
let mut player = SoundStreamPlayer::new(&mut music_stream);

[crumblingstatue]

In C++ was able to create my own audio stream handler like this

Looks like you are inheriting from sf::SoundRecorder. This seems to be another missing functionality in rust-sfml. There is no SoundRecorder. There does seem to be sfSoundRecorder, in CSFML though. This will have to be looked into.

I can see the trait sfml::audio::SoundStream but I see no implementors...

There are no default implementors. This is due to FFI limitations. We have to go through CSFML, which doesn't support inheritance like C++. There is an example for defining your own custom sound streams though.

Also the SoundStreamPlayer seems to be useless without any SoundStreams... even the example for it is missing the MusicStream

The SoundStreamPlayer is another workaround for having to go through CSFML. Since we can't use inheritance, we have to define a separate type for playing custom SoundStreams.

The example is for SoundStreamPlayer::stop specifically, and MusicStream is just an example for any custom SoundStream.

[crumblingstatue]

It's possible that we could come up with a different design for these types, but it's non-trivial work. If you're interested, you could help.

[petoknm]

The C API seems pretty intuitive... I think I'm gonna try to come up with a way to extend rust-sfml to support what I need to do... Not sure what kind of API i should expose for it though...

[petoknm]

My original plan was to just have something like a sound source type that has a samples() function that gives you back an Iterator<Item=SoundBufferRef> or something similar

[crumblingstatue]

172 adds this feature, so I'm closing.