pure-data VS plugdata

Report bugs on the pd github https://github.com/pure-data/pure-data

You might be interested in clicking through the puredata source code.

https://github.com/pure-data/pure-data

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

> Any criticism or unwelcome suggestions are treated as an insult to Miller Puckette and the proponent is attacked, ignored, or advised to implement it themselves (ie to go away and not come back).

I don't think this holds for the general case, but there a certainly a few users caught up in Stockholm Syndrome :-) I can assure you that the developer team (which I am a part of) is very well aware of Pd's limitations and problems. Pd has seen quite significant UX improvements over the last few years, but the pace of development is very slow. Anyway, if you have specific criticism, suggestions or feature requests, feel free to open a ticket on GitHub: https://github.com/pure-data/pure-data.

As a side note, the minimalistic GUI itself won't change since it is an intentional design decision by Miller, but there is some effort to abstract the core/GUI communication to allow alternative GUI implementations. (Personally, I really dislike the current Tcl/Tk GUI - not because it's minimalistic, but because it's slow and buggy.)

> and idiosyncratic terminology (eg PD refers to module connectors as 'patch cords' just like on an analog modular synthesizer or mixer, but what synth people commonly call a pulse or a trigger is a 'bang' in PD).

Pd's 'bang' belongs to the control/event domain, you can't really compare it to trigger/pulse in modular synthesizers. (FWIW, there are several Pd externals that implement audio-rate triggers.)

> You can make it do anything, but unless you already have a very specific goals you will spend most of the time reinventing wheels in parameter space.

That's a fair point. It's important for people to understand that Pd vanilla is really a programming environment with only a minimal set of built-in objects that allow you to build higher-level abstractions. You definitely need a set of "abstractions" or libraries to be productive. Fortunately, there are many existing Pd libraries and they can be easily installed with Pd's package manager "Deken". The most extensive one is "ELSE" with nearly 500 objects, containing everything from band-limited ocillators, filters, sequencers, GUIs, etc. Personally, I have my own collection of abstractions that I made over the last years.

That being said, I would agree that you should always pick the right tool for the job. Just as you wouldn't write your website in C, you wouldn't pick Pd for typical EDM stuff (unless you have a very good reason). But for prototyping and experimental electronics it's a fantastic tool, I think.

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.