Skip to content
A crate for developing audio plugins and applications in Rust, with a focus on software synthesis.
Branch: master
Clone or download
Type Name Latest commit message Commit time
Failed to load latest commit information.
examples Use midi-consts crate. (#66) Feb 17, 2020
tests Cargo fmt Jul 19, 2019
.gitignore added synth module & init commit Jun 8, 2017
.travis.yml Add extra backend, add more convenient way for specifying meta-data (#40 Dec 13, 2019
Cargo.toml Use midi-consts crate. (#66) Feb 17, 2020 Update Dec 20, 2019 Move design docs (#64) Feb 9, 2020


A crate for developing audio plugins and applications in Rust, with a focus on software synthesis. Rsynth is well suited as a bootstrap for common audio plugin generators. It handles voices, voice-stealing, polyphony, etc. so the programmer's main focus can be DSP.

Rsynth has the following components:

  • An API abstraction layer
  • Glue code for different API's (called back-ends). Currently supported are
    • rust-vst
    • Jack
    • offline audio rendering (from/to .wav and .mid files)
  • Middleware components that you can put between your code and the abstraction layer to provide various functionalities:
    • polyphony
    • ...


The documentation can be found

  • on for the version that is distributed via
  • on GitHub pages for an irregularly updated documentation of the master branch
  • on your local machine after running cargo rustdoc --features all for the most up-to-date documentation


There are full examples in the examples folder in the source code.

Current State

rsynth is in its early stage of development and many changes are breaking changes. There is currently no support for GUI's. The team behind it is very small, so progress is slow.


We try to focus on features that we are actually using ourselves. This helps to ensure that the features that we provide, can actually be used in practice. So if you want to use a particular feature that isn't there yet, feel free to open an issue (if needed) and you can volunteer to test the feature before it is merged.

In the long term, rsynth can be split into multiple crates for maximum re-usability and for license clarity (e.g. when one back-end requires a different license). We're currently keeping everything together because it's easier to coordinate breaking changes over the various components in this way.


Contributions and suggestions are welcome!

In order to avoid pull requests from being broken by other changes, please open an issue or have an issue assigned to you before you start working on something. In this way, we can coordinate development. Issues labeled with "good first issue" should not conflict too much with other changes that are in flight, but better check before you start working on one.

Don't worry if you only have a partial solution. You can still open a pull request for that. You can definitely split the solution for an issue into different pull requests.

Pull requests should be opened against the master branch.


In order to run all tests, run the following:

cargo test --features all

If you have trouble running this locally because you do not have jack-related libraries installed, no worries: you can still open a pull request; this will automatically trigger a CI build that runs all tests for you.

Code formatting

Please use cargo fmt to format your code before opening a pull request.

Tip: you can auto-format your code on save in your IDE:


Alexander Lozada's contributions to rsynth are helped by, a virtual instrument website.


The source code of rsynth is licensed under the MIT/BSD-3 License.

Note that in order to use rsynth in combination with other crates (libraries), the combined work needs to comply with the license of that crate as well. In particular, the following optional dependencies may require your attention:

  • the hound crate (behind the backend-file-hound feature) uses the Apache license, see its readme for more details
You can’t perform that action at this time.