[spacechild1]

> 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...).

[singingfish]

> Pd was developed in the mid 90s

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 :)

[chaosprint]

Do you think rewriting pd in Rust can be a good solution?Async in Rust is one of its selling points:

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

[spacechild1]

No, I don't think that Rust would buy us anything in this regard.

"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 :-)

[chaosprint]

I see. Was just thinking aloud.

[spacechild1]

(BTW, I did not downvote your comment. I know that you have actually written audio code in Rust and therefore assumed it was an honest question from your side :-)