Next week, I travel to Bali to focus on developing a data flow based visual music synth. I can't understate how big an influence that Puckette's work has been on my thinking.
The other advantage is because these things were implemented in the 80s when real time audio was a really big ask for computers, they are very computationally efficient.
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...).
https://rust-lang.github.io/async-book/
There are some good gui tools in Rust as well:
https://www.egui.rs/ https://github.com/setzer22/egui_node_graph
"Async" in languages like Rust are meant for an entire different problem domain (mostly networking).
In my post above I'm talking about dispatching commands from the audio thread to a helper thread (pool) - and back. This has to be done in a realtime safe manner, so a general async framework won't be appropriate.
> There are some good gui tools in Rust as well:
I don't think GUI programming is exactly one of Rust's strengths :-)
Fair enough. Life was still pretty computationally constrained until the mid 00s mind you, so there's still an efficiency dividend here.
Nice work on the patchsets by the way - well beyond my abilities :)