Maintainership status and crates.io release
What is maintainership status of this library? Should it be considered abandoned?
If not, when is the next crates.io release expected?
I think for the most part hound already does what most people need it to do, and that's why the repo is quiet.
@ruuda has always been responsive to issues and PRs whenever I've submitted anything.
Are you currently waiting for some feature to land in a new crates.io release?
Are you currently waiting for some feature to land in a new crates.io release?
Primarily things for outputting wav files to stdout or reading them from stdin, like https://github.com/ruuda/hound/issues/39 or https://github.com/ruuda/hound/pull/36.
I don't typically use wav files as a storage medium for audio, just as a intermediate representation to get it to/from some filtering application.
I think for the most part hound already does what most people need it to do, and that's why the repo is quiet.
I think making a minor release once in a blue moon may be beneficial, even if just to show that the project as active.
For there are a number of things already in master, but not on crates.io.
Thank you for taking the time to open an issue. I wouldn’t call the repository abandoned, I intend to make a new release with everything that’s on master. But to be honest, I’ve been wanting to do that for more than two years, and I haven’t gotten to it yet.
If it was a simple matter of publishing the crate, I would have done it a long time ago, but there are a few issues with the current state. #26 in particular, but I also think some of the interfaces can be simplified, so I don’t want to make a new release now with quite a few new features that have accumulated, and then introduce many breaking changes in the release after.
I understand that it’s frustrating to wait for a new release. I hope I can find the time to make a new release soon.
I just published 3.5.0 which includes #36. I cherry-picked the contributions that were compatible on top of 3.4.0 for that release, there are other changes on master still unreleased. I still plan to get to those, but I hope this helps in the meantime.
Is 3.5.0's design compatible with reading wav from pipes (0xFFFFFFFF lengths everywhere)?
Looks like no, as https://docs.rs/hound/latest/src/hound/read.rs.html#735 would eventually abort reading file even if initialisation succeeds. num_samples should be either Option<u32> or have some signaling value to signify infinite files.