pure-data VS plugdata

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

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

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.

Max4Live is what got me into Ableton, it also got me out of Ableton...

As someone who had been using PureData for quite a while the idea of having that kind of development environment integrated into the DAW was super exciting, unfortunately the actual implementation leaves a lot to be desired; personally the final straw was when I realized that the Max process space was global to Ableton so that global variables would leak between devices (no sandboxing)... This may have been addressed in further releases as I was a very early adopter, but all of the other issues pointed out by the other posters still stand.

If you're looking for a platform agnostic alternative to Max4Live there is PlugData[0] which is a VST implementation of PureData -- the open-source origin of Max and created by the same authors.

And there is the Grid for Bitwig[1] which offers a modular graph based MIDI/DSP programming environment that runs at audio rate and is fully integrated into the DAW as a native solution! The Grid is somewhat limited as it isn't extensible, but it supports >95% of common use cases and is used internally to build Bitwig's native devices. Hopefully in the future Bitwig will extend it's open API surface to include building custom Grid modules -- in the meantime PlugData is perfectly acceptable patch for doing unusual logic calculations and doing left-field things like interfacing with robotics :)

[0] https://plugdata.org/

Automatonism is ongoing, and if you're looking for better UX (as well as a ton of other excellent features, like making plugins and compiling for Daisy) then you should absolutely check out https://plugdata.org!

Sweet! It works now in plugdata, too!

An alternative for this is PlugData -- a native VST host for PureData (the open-source sibling of Max; same original author)

The Rust audio environment might need help, if you're into that:

https://rust.audio/

Maybe this might be worth a look, too:

https://plugdata.org/

It's a recent attempt to make Pure Data more accessible for less technically inclined users.

Well, Miller created Max, which back in those days was more about composition than synthesis and relied on external hardware to create sound. Another fella took Max and developed the commercial product and developed it some more. During this time home computers became good enough for realtime synthesis so Miller developed PD which combined aspects of Max with realtime audio synthesis capabilities. Max thought this was pretty great so integrated pd into Max which gave us Max/MSP, Max is Max Mathews who developed the Music(n) family of programing languages and MSP is Miller S. Puckette.

I would not say that pd or Max/MSP is more approachable, they are pretty even these days unless you stick to vanilla pd with no externals which almost no one does, the main differences is that Max/MSP gives you all you need out of the box but pd can run just about anywhere including in plugins if you are that sort. Max/MSP is considerably more modern in aesthetic but PlugData[0] and PurrData[1] offer more modern interfaces for pd with a few new tricks, PlugData is a plugin version of pd (also standalone), Purrdata is a JavaScript rewrite of the interface with prepackaged externals and solid documentation. And we have a handful of other varieties of pd each which have their own slant and can be found on puredata.info.

0: https://plugdata.org

Not a programmer, but a producer here, and I’m interesting in getting into programming and I don’t know much about it but I want to learn JUCE (and Pure Data; which I know is also available now as a vst! and here’s a link for that https://github.com/plugdata-team/plugdata

This is an important objective of the rapidly-progressing plugdata project! The patcher is based on pure data so you can live patch yourself into deep space with any GP computer (a RasPi works fine), but has a sleek, calm, efficient, and themeable UI. In the last couple of weeks has grown a compiler that is working in its preliminary form both compiling in to C and flashing a Daisy synth dev board. The eventual hope is to gain compatibility across microcontrollers for not just audio synthesis, but for any creative purpose.

The project is here: https://github.com/plugdata-team/plugdata

The builds are coming thick and fast. 0.6.2 is so far behind the daily builds right now that 0.6.3 is going to be an enormous leap in functionality. Tim and the development team are doing a spectacular job of staying focused and cranking out bugfixes and features sometimes multiple times a day.