Pukette got the shits with the conditions of his grant from the french government that allowed the development of Max, because it disallowed him to use the same techniques to do visual synthesis. So he quit and reimplemented the whole thing. Except this time he used an open source license.
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.
> 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.
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 :-)
(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 :-)
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.