I'll upload the current state of things on Github as soon as I can. What I should do first is complete the writeup that explains my approach and provides guidelines. Although there are not many sound-producing gadgets available yet (as I'm writing these lines, only a phaser!), the general design is ready for comments, and things should move much faster now.
The Sample library was my inspiration: it was a mind-expanding revelation for me that iterator-like objects will give you an API that's both efficient and easy to use, even when you change sample rate. But I think that ordinary Rust Iterators, as used in Sample, are not suited for audio, so I designed my own Signal trait. In addition to the .next() method there's a need for an .init() that takes account of the parameters known only at runtime, like sample rate. And Sample's choice of RefCell<Rc<T>> (if my memory serves me) when an output needs to feed many inputs is quite inefficient. So my other important design choice was to use &Cell<T> for sharing signals. But this makes my framework impossible to use when audio streams have a 'static lifetime, which is the standard for 90% of audio ffis in Rust, so I spent the last three weeks trying to find a workaround. I finally got to hear a sound on my MacBook by tweaking mitchmindtree's coreaudio-rs port.
It's great to hear that you can now write Supercollider UGens in Rust, and I like your idea of a Rusty approach to multi-threading, which should be quite efficient.
So I'll keep in touch, that's for sure.