4 ms·

To be honest, I've spent many hours in PD and Max and didn't realize that Miller Puckette was behind both. Super cool! Next week, I travel to Bali to focus on

To be honest, I've spent many hours in PD and Max and didn't realize that Miller Puckette was behind both. Super cool! 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.

singingfish 4y ago
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.
- deleted 4y ago
  [deleted]
- spacechild1 4y ago
  > 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 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-threading https://github.com/Spacechild1/pure-data/tree/multi-threadin...).
  - chaosprint 4y ago
    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/ https://rust-lang.github.io/async-book/ There are some good gui tools in Rust as well: https://www.egui.rs/ https://www.egui.rs/ https://github.com/setzer22/egui_node_graph https://github.com/setzer22/egui_node_graph
    - spacechild1 4y ago
      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 4y ago
        I see. Was just thinking aloud.
    - spacechild1 4y ago
      (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 :-)
  - singingfish 4y ago
    > 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 :)

singingfish 4y ago

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.

deleted 4y ago
[deleted]
spacechild1 4y ago
> 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 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-threading https://github.com/Spacechild1/pure-data/tree/multi-threadin...).
- chaosprint 4y ago
  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/ https://rust-lang.github.io/async-book/ There are some good gui tools in Rust as well: https://www.egui.rs/ https://www.egui.rs/ https://github.com/setzer22/egui_node_graph https://github.com/setzer22/egui_node_graph
  - spacechild1 4y ago
    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 4y ago
      I see. Was just thinking aloud.
  - spacechild1 4y ago
    (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 :-)
- singingfish 4y ago
  > 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 :)