MOZGIII

This is still relevant for me. It feels like the `Frame` type itself should not be specified over the channels amount. This wouldn't be a problem if the `Signal` type...

I did some experiments, and it definitely looks like the `Frame` trait that we have currently is too tightly coupled with the implementations. `Frame` with dynamic channel amounts (unknown at...

I created #114. Also, I'm working on some code in my project to solve this issue, I may submit a PR to `sample` here once I get it done.

I suffered quite significant difficulties with using `Frame` type during my experiments, mainly because `Frame` type is expected to be owning, not referencing `Sample`s. This seems like a major concept:...

Cool! I'd be happy to share my results with you, and discuss how to fix the usability of the crate. I've been stuck with this for about a week now,...

Why use a macro when it seems like it can be just a generic type, and a part of `failure` crate?

> Should `Source::count` return a `Result` instead of a plain `usize`? What if we move the `Source::count` to a separate trait: ```rust trait SourceCount: Source { fn count(&self) -> usize;...

Given all that, I'm having hard time imagining a case when the `count` would be `None` (or `Err`). Do you have an example in mind? How is the `count` used?...

> Hmm, I don't think the current implementation really supports this kind of scenario because pairs can be visited and fetched at any point. I also don't think it's really...

It's in since 0.54. What now?