Pure Data: an open source visual language for multimedia
puredata.info
puredata.info
Fun fact: miller Puckette, pd's author, also wrote the first versions of max/msp, but the IP was owned by the university he worked for at the time. IRCAM? I can't remember, but that led to cycling74 spinning it off, cultivating jitter and eventually gen~ while being bought up by Ableton.
Great histories, great math, arguably great code. It acts like the proverbial gateway drug, addicting musicians and artists to programming in text. I like Visual programming, but the paradigms themselves are pretty transferable to event oriented environments.
You may find better instruction material than you had in the past in the excellent Csound Floss manual.
On top of all that, there are externals for Max and Pd to run Csound within those environments. You can get the best of both worlds! Csound is still very relevant and useful.
(Rest in peace, Darwin Grosse. His work is probably familiar if you're a computer music person, and worth checking out regardless.)
Brian Eno used it to create the music for Spore.
https://en.m.wikipedia.org/wiki/Development_of_Spore
https://lists.puredata.info/pipermail/pd-list/2007-11/056307...
It's sort of a custom GUI tool for the Pd patch you create.
The first was an acoustic-electronic room reverb stimulator. We set up multiple mic+speaker pairs in a room and used PD to allow the user to set a delay on each mic input before reproducing the sound out of the matched speaker, to simulate sound propagation in a larger room. The signal was also filtered with a selectable frequency response that could be set to match a list of different materials. The result was real time simulated reverberation on physical space. This was really easy to patch together in PD, rather than using a general purpose programming language.
The second project was the Mmm-What-You-Say-O-Tron, a phase vocoder inspired by the instrument Imogen Heap uses to perform her song Hide and Seek. This was a much more sophisticated patch, which used PD's MIDI capabilities, pitch extraction, and a custom pitch-shift algorithm. It was less successful, but still really fun.
I have always liked this example: https://www.youtube.com/watch?v=yW1haAOxWWk. I'm not sure if the music was also created in Pure Data. It kind of sounds like it. There are loads of other examples like this on YouTube.
If you're interested in Pure Data, I recommend the following two books:
* Multimedia Programming with Pure Data: https://www.amazon.com/gp/product/1782164642
* Programming Sound with Pure Data: Make Your Apps Come Alive with Dynamic Audio: https://www.amazon.com/gp/product/1937785661
It won't change so that Knuth can finish:
https://forum.freecadweb.org/viewtopic.php?t=51429
but couldn't manage to wrap my mind around FreeCAD so as to benefit from it.
Max looks much nicer, but they both have the same problem: Lack of community.
I expected to be able to treat PureData or Max like any other programming language: find a book, watch some tutorials, and get up to speed.
Additionally, there isn't really a central "repo" for PureData. I want to search through patches that people have shared for learning and re-use purposes. However, I am unable to find such a thing.
https://patchstorage.com/ has been making a pretty heroic effort at being a searchable hub for, pure data in the beginning, but now many.
The forum is the most active for posting patches, but is terrible at indexing. https://forum.pdpatchrepo.info/category/2/patch
Puredata.info was the historic one right? Even though I remember using sourceforge a lot. Some interesting things there, but I don't think people post patches or even plugins on the main site much anymore. On the sourceforge note, plenty in GitHub too. Sometimes, /r/puredata
Pd's creator was originally a mathematician and IIRC he said that the look he was going for is that you start off with a clean sheet of white paper and draw simple figures and lines on it
PD's interface is stuck in the 1980s, with the monochrome graphics, lack of any support functionality (contextual menus or rearrangement/tidying functions, snapping) 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). And its users mostly like it that way, the same way some people fetishize 8 bit videogames.
There have been more accessible versions of the same idea for a long time (ie the mid-90s), from Clavia's Nord Modular in hardware and Native Instrument's software synth Reaktor in the commercial space to solo projects like Ross Bencina's Audiomulch. The latter was very obviously inspired by PD but iterated on every aspect of the design, making it far more accessible and flexible.
PD's defenders (kinda like CSound's) emphasize how open-ended it is and that you can do anything, render any concept etc. In the audio synthesis world it's well understood that the more a manufacturer emphasizes unlimited creativity, massive patch storage, infinite potential etc., the less good the UI and the more basic the default quality of the sound engine. 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. If you want a mature technology stack for implementing an audio subsystem (eg in a game), it might be a very good choice. If you just want a flexible tool to make electronic music, it's best avoided.
I agree so much. It's a cool tool but the curve to learn it is often not worth it
Nicely illustrated by reductio ad absurdum: a "naked" Epyc with a few sticks of RAM, an NVMe and a pair of A/D in the upper kHz range would score quite well in "unlimited creativity, massive patch storage, infinite potential etc", but you'd spend quite some time reinventing wheels (e.g. this gets less bad if you add a compiler).
That’s the nature of many musical instruments.
Not the kazoo of course, and if that’s your jam it’s cool by me. But it probably won’t get you to Carnegie Hall and that’s also cool by me.
Which is to say that in a community of musicians, complaining that developing chops is hard work doesn’t have much traction.
It doesn’t have much traction because even Garage Band requires commitment to achieve competence. It only produces slightly less poor to mediocre work easily.
But I completely agree that 2500 patches is not necessarily better than 64…a lot of dance music was made with a 303. Live no less.
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.