An audio signal processing library in Rust.
The design, and general usage, of this library is based on the Synthesis Toolkit which is hosted by CCRMA and written in C++.
All objects intended to process samples of an audio signal implement the Processor
trait. Samples are passed into the object using process()
and returns an output sample.
- Generic support for
f32
andf64
samples - Basic digital filters
- RBJ filters
- Integer and linear-interpolating delays
- Peak and RMS envelope detectors
- Window function iterators
- Analog filters, based on DSPFilters by vinniefalco
-
filter::butterworth
-
filter::chebyshev1
-
filter::chebyshev2
-
filter::elliptic
-
filter::bessel
-
filter::legendre
-
-
delay::AllpassDelay
, an all-pass interpolating delay-line (seestk::DelayA
) - Improved unit tests
- More inline-examples
-
examples/effects
- Ping-Pong Delay
- Compressor
- CombFilter?
- Chorus
- Flanger?
- Phaser?
- PitchShifter using a variable delay line
- Echo?
- Simple reverb?
-
mod generators
-
mod oscillator
-
mod envelope
-
-
mod oscillators
Support of basic waveforms: Sine
, Triangle
, Square
, and Saw
. There are multiple implementations for oscillators, depending on the waveform. This list is not comprehensive.
-
mod envelope
-
Adsr
-
Ahdsr
-
Ar
-
-
util::time
, a time conversion utility? -
mod interpolate
? - FFI?
- A Ruby-inspired syntax?
4.milliseconds.to_samples::<f32>::(44100f32) -> 44.1f32
4.milliseconds.to_samples::<usize>::(44100f32) -> 44usize
Justification, or "Why I don't want to use time_calc
"
time_calc
is designed for general time calculations, which is useful when creating a daw for example- So
Samples
intime_calc
is an alias fori64
, whereas time-based components in this crate rely onusize
orf32
time_calc
also includes converions that wouldn't be used in this crate (SampleHz
,Ticks
,Ppqn
)
- So
TL;DR: time_calc
represents samples for a different use case that's uncessary for this crate
Mainly for parameter smoothing functions
- Linear, lagrange, and other forms of interpolation?
Whether this is implemented or not, docs must be updated to note lack of parameter interpolation
- So discontinuities when changing parameters with an live signal are possible
If added...
- Export to C
- Header files for C++?
- Package as a JUCE module?
Argument against...
- DSP could just be done entirely in rust and abstracted as a single struct
- User can create C bindings themselves
-
mod formant
-
mod pluck
Pluck-string model (seestk::Twang
) -
FFT/IFFT
andSTFT/ISTFT
implementations