I’m super proud to have released version 0.1.0 of
rsynth to crates.io.
rsynth is mostly an abstraction layer for different audio “backends” (jack, vst, …), but it also has some utilities for “streaming” audio processing.
The previous version, version 0.0.1 was published nealry two years ago by @doomy and a lot has happended then since.
Most obviously, @doomy has transferred
rsynth to my account. Thanks a lot for the trust you place in me, @doomy !
Also on a technical level, a lot – nearly everything – has changed.
- Added support for
jackas a backend
- An abstraction for audio buffers (it’s not obvious when you read the source code and using it is rather smooth, but oh my, this caused me a lot of headscratches to get the borrow checker happy)
- Support for offline rendering
- A backend independent mechanism for specifying meta-data. It also has a “user friendly” way for specifying the eta-data, but maybe it’s a little to “automagic”? I don’t know, future will tell.
- Lots of edits to the documentation
- Two crates were developed specifically for
midi-consts(+ two extra crates that I would not recommend and that are no dependencies of
- Lots and lots of refactoring big and small
There are also some things that didn’t make it to this release
- The concept of middleware and pipleines, similar to what you have in web development. This didn’t make it for a good reason: it just adds a lot of complexity and compile times for no real gain.
- Support for reading midi files with rimd. I removed it because I was using the master branch from GitHub and crates.io only supports specifying dependencies from crates.io. See this issue for more info. It’s a pitty, but nothing that can’t be solved in the future.
What’s in there for the future?
Telling the future is not one of my capabilities, but if we look back at two years of history now, we see that
rsynth development has been rather stable for a long time. The git logs do not always show that because I tend to squash my own commits now (who looks at previous versions anyway?) and because I have also been trying out
rsynth in some private projects.
rsynth has been an ongoing effort for nearly two years now and we can expect it to continue in the future.
Nevertheless, let’s be honest:
rsynth is a one-person project right now, so there are some constraints. We’ve all seen some of the best people in the Rust community get burn-outs and, while there are currently no signs of that happening to me, it’s something to watch out for.
The most important aspect, I think, is scope management: keeping the scope small enough so that it’s still doable for one person. In practice, this means limiting the scope to only features that I personally use. This has the additional benefit that it’s all tested: it’s not just an API that can be used in theory, you can also use it in practice.
So, what’s in features will I likely need in the future? It’s hard to tell, but it’s probably better envelopes (the ones that are in there right now are rather embryotic) and support for
Does this mean there are no other features possible? Definitely not. If there is something you would like to see, you can open a pull request. Also,
rsynth is designed to be modular, so not everything needs to be in the
rsynth crate or repository.
Edit: writing and editing this post and discussing it with a friend made me understand that the scope of
rsynth is in fact too vague and too broad. So the future of
rsynth is probably focusing on API abstractions and moving everything else (polyphony, envelopes, …) to separate crates.
Whether you will use
rsynth or not … happy coding!