3 ms·

That is a great question. While I'm not going through all the dependencies, I can give a brief overview. First off, a lot the crates we use are actually just b

That is a great question. While I'm not going through all the dependencies, I can give a brief overview. First off, a lot the crates we use are actually just bindings or abstractions over these essential parts such as os-specific windowing stuff. Winit and Glutin are the main examples. For OS audio stuff, there is cpal, but we found that the way it's designed is not the best for a DAW (no duplex support or MIDI). We may end up creating our own solution under the rusty-daw-io repo, although someone is also looking into creating bindings to RTAudio. We are using femtovg in place of cairo. The developer of our GUI library is also working on improving the text layout and shaping inside femtovg. We are using Symphonia for decoding audio files (although we may end up binding to ffmpeg if it doesn't work out). We aren't using any networking in mvp, but there is no shortage of networking crates in rust. We will also likely use bindings to libsamplerate if we find that a native Rust one is not good enough. I don't recognize a lot of those dependencies. If there is a crucial one I missed, please let me know! Of course some would point out why use Rust if you are using so many non-Rust dependencies? That is a fair argument. Me and my team just really prefer writing in Rust, so we are willing to put in the extra effort of using bindings.

PaulDavisThe1st 5y ago
A large chunk of those libraries come the depstack of our GUI library (GTKmm). Pango, Harfbuzz etc. are all just dependencies for the GUI library, but also our own Canvas library (we had to write our own, since nothing out there came close to requirements; the Canvas is heavily Cairo-based but could fairly trivially be ported to any 2D drawing API). More DSP-y/audio-centric libraries would include: fftw - fastest fourier transform in the west rubberband - the only open source stretcher worth using (though we do have code to use soundtouch also) lilv,serd,sord,sratom,suil - LV2 infrastructure vamp-plugin-sdk - for offline (non-realtime) audio analysis aubio - used by VAMP liblo - almost certainly the best FLOSS OSC library We created our own audio/MIDI I/O abstraction initially based on JACK (which was initially based on Ardour :). The Windows version uses PortAudio which has its pros and cons; the macOS version directly uses CoreAudio; the Linux version directly uses ALSA (and then there is a separate cross-platform JACK one too).
- BillyDM 5y ago
  Nice. I have not heard of rubberband. I'll definitely take a look into it! For FFT I believe there is a native fft crate in rust which we'll likely use. I just haven't gotten around to making any spectrometers yet. We're not using any OSC in the mvp, but I'll keep those libraries in mind. Someone else is independently working on their own LV2 and VST hosting crate, which is what we'll use too. We may need to end up implementing our own VST3 and AU hosting code when the time comes. The goal of the rusty-daw-io crate is pretty much what you described in creating an abstraction over Jack, Pulseaudio, CoreAudio, and Alsa. Although I'm going to see if using bindings to RTAudio could save us time and effort here. Also, what do you use offline audio analysis for? Sounds interesting.
  - PaulDavisThe1st 5y ago
    The offline analysis is for now used only for transient detection (so you can split by transient, and potentially "conform" a transient-laden track (e.g. percussion) to fit the tempo). I wanted to use VAMP for tempo detection as part of the new clip launching features, but found that the code it uses really doesn't work well on short (1/2/4 bar loops). I ended up (for now) using Minibpm, a single-file implementation from Chris Cannam, who is responsible for both rubberband and VAMP. It's not perfect. but for the most part it works really well. Even the Live manual notes that they will sometimes "guess" the tempo incorrectly, typically by a factor of 2 in either direction.
    - BillyDM 5y ago
      Neat!

PaulDavisThe1st 5y ago

A large chunk of those libraries come the depstack of our GUI library (GTKmm). Pango, Harfbuzz etc. are all just dependencies for the GUI library, but also our own Canvas library (we had to write our own, since nothing out there came close to requirements; the Canvas is heavily Cairo-based but could fairly trivially be ported to any 2D drawing API). More DSP-y/audio-centric libraries would include: fftw - fastest fourier transform in the west rubberband - the only open source stretcher worth using (though we do have code to use soundtouch also) lilv,serd,sord,sratom,suil - LV2 infrastructure vamp-plugin-sdk - for offline (non-realtime) audio analysis aubio - used by VAMP liblo - almost certainly the best FLOSS OSC library We created our own audio/MIDI I/O abstraction initially based on JACK (which was initially based on Ardour :). The Windows version uses PortAudio which has its pros and cons; the macOS version directly uses CoreAudio; the Linux version directly uses ALSA (and then there is a separate cross-platform JACK one too).

BillyDM 5y ago
Nice. I have not heard of rubberband. I'll definitely take a look into it! For FFT I believe there is a native fft crate in rust which we'll likely use. I just haven't gotten around to making any spectrometers yet. We're not using any OSC in the mvp, but I'll keep those libraries in mind. Someone else is independently working on their own LV2 and VST hosting crate, which is what we'll use too. We may need to end up implementing our own VST3 and AU hosting code when the time comes. The goal of the rusty-daw-io crate is pretty much what you described in creating an abstraction over Jack, Pulseaudio, CoreAudio, and Alsa. Although I'm going to see if using bindings to RTAudio could save us time and effort here. Also, what do you use offline audio analysis for? Sounds interesting.
- PaulDavisThe1st 5y ago
  The offline analysis is for now used only for transient detection (so you can split by transient, and potentially "conform" a transient-laden track (e.g. percussion) to fit the tempo). I wanted to use VAMP for tempo detection as part of the new clip launching features, but found that the code it uses really doesn't work well on short (1/2/4 bar loops). I ended up (for now) using Minibpm, a single-file implementation from Chris Cannam, who is responsible for both rubberband and VAMP. It's not perfect. but for the most part it works really well. Even the Live manual notes that they will sometimes "guess" the tempo incorrectly, typically by a factor of 2 in either direction.
  - BillyDM 5y ago
    Neat!