Open m4b opened 7 months ago
I'd also (strongly) suggest that the binary, fii, have their deps split out; e.g., libc isn't required by the library, etc., clap isnt' required by the library, etc., and probably several others I haven't looked at. Additionally, the ffi stuff should be a feature flag so users don't need to compile/include it if only using the rust library. Much of this might partially/completely address the deps issue in point 3. above :)
One last point, you may want to consider a single return Vec, with e.g., Vec<Analysis>
, where e.g.:
pub struct Analysis {
freq: f32,
voiced: bool,
prob: f32,
}
Analysis is just a random name I chose, I'm sure there are better. This will have better cache locality, and users don't have to access other data via zipping, or indexing, etc.
I understand this diverges from the python api, but it is also more rustish to do this.
Thank you for your suggestions. I have not much experiences making Rust libraries. I will be grateful if you make PRs for them. If you can't, i will do it some day when possible, and will request your review.
I've worked some of your suggestions. Please check v1.2.0 release note. I couldn't do no. 2, 3 of your suggestions, because It required much work that I can't handle now. Again, I'll do them when possible. Thanks.
Hello,
This is really cool you ported this algorithm to rust, thank you for all your work! Ideally a (rust) PSOLA algorithm with this would allow very simple but interesting audio manipulations of spoken voice, for example.
So I'm wondering if you have any plans to make the api more "idiomatic rust", specifically, here are a couple issues I encountered and which I think could improve:
CowArray
forces users to explicitly depend on ndarray; more idiomatic would be e.g., a&[T]
or&[f32]
or&[i16]
, depending on how this gets done. I also understand this gets more complicated when there are multiple channels, but it might be nice for a "simple" api that accepts a(&[f32], usize)
or something that has num channels, etc., so there is less burden on the user to convert to appropriate types, etc. For example, this is a lot of type manipulations just to get that CowArray (I had to look at your binary to even see how to do this, since i don't use ndarray at all):I'd prefer something like:
Note that the returned objects are regular vecs, and user doesn't need to know about ndarrays or cows arrays or whatever, etc.
&mut
), and the current api calls this internally with local vecs as the inouts and returns those. (of course this would also likely depend on above, using vecs as returns etc.)Regardless whether you make it more idiomatic or not, thank you so much for writing this in rust, really great stuff! :)