pure-data
vst-rs
pure-data | vst-rs | |
---|---|---|
3 | 7 | |
8 | 1,033 | |
- | - | |
0.0 | 1.7 | |
about 1 month ago | 11 months ago | |
C | Rust | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pure-data
-
Pure Data as a plugin, with a new GUI
> The other advantage is because these things were implemented in the 80s
Pd was developed in the mid 90s
> they are very computationally efficient
Not as efficient as it could be, though. For example, instead of proper SIMD instructions, the DSP perform routines only use manual loop unrolling, praying that the compiler will auto-vectorize it.
Finally, everything is single-threaded, leaving lots of performance on the table. FWIW, I have a PR for an asynchronous task API (https://github.com/pure-data/pure-data/pull/1357) and also a branch for multi-threaded DSP (https://github.com/Spacechild1/pure-data/tree/multi-threadin...).
-
Show HN: Glicol(Graph-Oriented Live Coding Language) and DSP Lib Written in Rust
FWIW, Pd and Max/MSP always had sample-level control in the sense that subpatches can be reblocked. For example, if you put a [block~ 1] object in a Pd subpatch, the process function will be called for every sample, so you can have single-sample feedback paths. Pd also has the [fexpr~] object which allows users to write FIR and IIR filters in a simple expression-syntax. Finally, Max/MSP offers the very powerful [gen~] object. You can check it out for inspiration (if you haven't already).
Pd (and Max/MSP) also allow to upsample/resample subpatches, which is important for minimizing aliasing (caused by certain kinds of processing, such as distortion).
Pd also uses the reblocking mechanism to implement FFT processing. The output of [rfft~] is just an ordinary signal that can be manipulated by the usual signal objects. You can also write the output to a table, manipulate it in the control domain with [bang~], and then read it back in the next DSP tick. IMO, this is a very powerful and elegant approach. SuperCollider, on the other hand, only supports a single global blocksize and samplerate which prevents temporary upsampling + anti-aliasing, severly limits single-sample feedback and leads to a rather awkward FFT implementation (you need dedicated PV_* objects for the most basic operations, such as addition and multiplication).
Another thing to think about is multi-threaded DSP. With Supernova, Tim Blechmann miraculously managed to retrofit multi-threading onto scsynth. Max/MSP offers some support for multi-threading (IIRC, top level patches and poly~ instances run in parallel). Recently, I have been working on adding multi-threading to Pd (it's working, but still very much experimental): https://github.com/Spacechild1/pure-data/tree/multi-threadin.... If you design an audio engine in 2022, multi-threading should be considered from the start; you don't have to implement it yet, but at least leave the door open to do it at a later stage.
---
I'm not sure how far you want to go with Glicol. I guess for the typical Algorave live coder all these things are probably not important. But if you want Glicol to be a flexible modern audio engine/library, you will have to think about FFT, upsampling, single-sample feedback, multi-processing etc. at some point. My advice is to not leave these things as an afterthought; you should at least think about it from the start while designing your engine - if you want to avoid some of the mistakes that other existing audio engines made. This is just a word of "warning" from someone having spent countless of hours in Pd and SuperCollider source code :-)
-
How a Single Line of Code Made a 24-Core Server Slower Than a Laptop
Great write up!
What I like about Pd is that you can freely reblock and resample any subpatch. Want some section with single-sample-feedback? Just put a [block~ 1]. You can also increase the blocksize. Usually, this is done for upsampling and FFT processing. Finally, reblocking can be nested, meaning that you can reblock to 1024 samples and inside have another subpatch running at 1 sample blocksize.
SuperCollider, on the other hand, has a fixed global blocksize and samplerate, which I think is one of its biggest limitations. (Needless to say, there are many things it does better than Pd!)
---
In the last few days I have been experimenting with adding multi-threading support to Pd (https://github.com/Spacechild1/pure-data/tree/multi-threadin...). With the usual blocksize of 64 sample, you can definitely observe the scheduling overhead in the CPU meter. If you have a few (heavy-weight) subpatches running in parallel, the overhead is neglible. But for [clone] with a high number of (light-weight) copies, the overhead becomes rather noticable. In my quick tests, reblocking to 256 samples already reduces the overhead significantly, at the cost of increased latency, of course.
---
Also, in my plugin host for Pd/Supercollider (https://git.iem.at/pd/vstplugin/) I have a multi-threading and bridging/sandboxing option. If the plugin itself is rather lightweight and the blocksize is small, the scheduling overhead becomes quite noticable. In Pd you can just put [vstplugin~] in a subpatch + [block~]. For the SuperCollider version I have added a "reblock" argument to process the plugin at a higher blocksize, at the cost of increased latency.
vst-rs
-
What would you rewrite in Rust?
https://github.com/RustAudio/vst-rs this what you mean?
-
How do you go about making VSTs?
I hate to "uhhmm ackchyually" this, but unless you need native VST3 support* (which uses the C++ ABI directly) other options are available, a favourite of mine would be Rust!
-
OctaSine v0.7.0 released (free and open source FM synth VST plugin for macOS/Windows/Linux) with major improvements
VST2 bindings exist (https://github.com/RustAudio/vst-rs) but the VST3 and AU situation is rougher around the edges. There is work being done on abstracting over different plugin standards and easing parameter handling, notably https://github.com/wrl/baseplug and https://github.com/robbert-vdh/nih-plug, but nothing completely stable yet.
-
Announcing Audio Limiter: automatically lower the volume of loud sounds on your computer in real-time
One limitation that they mention is "Only one GFX and one LFX APO can be registered for an output device and only one LFX APO can be registered for an input device." which could be a problem for people who are already using one like Equalizer APO. What you could do is make a VST version of your limiter using vst-rs and use Equalizer APO to handle the APO part.
-
Elementary Audio: a modern platform for writing high performance audio software
I agree with the first half. For the second half, I think for beginners, the examples are very important. From this perspective, many Rust projects comes with examples:
https://github.com/RustAudio/vst-rs
Once following the readme, it is very easy to get it work in your own machine. Then beginners can edit things while learning new stuffs with books or online resources.
Rust audio has also got a very helpful Discord community where beginners can always ask questions.
For the GUI part, I am not an expert, but there are more and more Rust GUI libraries (egui, iced, druid, rui): among them, egui-rs and iced-rs can all be used for VST. Still, there are some examples to get started with.
-
Show HN: Glicol(Graph-Oriented Live Coding Language) and DSP Lib Written in Rust
https://youtu.be/yFKH9ou_XyQ
If you want your own vst (with your name on the author and you can sell),you can start with vst-rs:
https://github.com/RustAudio/vst-rs
Wanna some GUI, here is a template:
-
OctaSine, a FM-based VST2 synthesizer written in Rust
When I came across the vst-rs, I realised that I could try out writing an audio plugin. Since I was already familiar with FM synthesis from Elektron Monomachine and FM8, I decided to go with it. It has worked out pretty well.
What are some alternatives?
faustgen-supercollider - Livecode Faust in SuperCollider using an embedded Faust compiler.
glicol - Graph-oriented live coding language and music/audio DSP library written in Rust
egui_baseview_test_vst2 - Barebones egui_baseview vst2 plugin with basic parameter control
adsb_deku - ✈️ Rust ADS-B decoder + tui radar application
ddwChucklib-livecode - A live-coding interface for chucklib objects
faust - Functional programming language for signal processing and sound synthesis
ixilang - A live coding language. An extension to SuperCollider, currently Cocoa only.
vst3-sys - Raw Bindings to the VST3 API
hvcc - The heavy hvcc compiler for Pure Data patches.
OpenAudio - A list of open source VST/audio plugin projects. Please contribute more links or open source your own plugins.
egui_node_graph - Build your node graph applications in Rust, using egui
duplicate - Easy code duplicate with substitution for Rust