This is like object oriented c, meant for real-time mostly but I honestly use it most for sample processing and synthesizer design. Fantastic software.
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.
It was my fortune to interact and discuss dsp with him many times around 7 years ago. He is missed. I'm glad his forum posts and podcasts are probably still helping, or entertaining, people everyday
MSP is Miller S Puckette.
C Sound was the precursor to many of the visual and OO music programming languages, but needed to be compiled and was, well, difficult. Supercollider was heavily influenced by Max/MSP. David Zicarelli of C74 fame had a background in psychology before programming. Kit Clayton wrote the first version of jitter. Autechre are probably the best known artist for using all of the above mentioned software in some form.
Seeing your use of past-tense here, I have to plug: I'm a 25 year+ Csound enthusiast. Still very happily composing with Csound along with the rest of the small but committed community. Being a lifelong programmer, I prefer it to Pd, Max and Supercollider, and think many HN folks would too.
Yes to this! For many purposes, Csound is hard to beat. It has some truly incredible sounding opcodes, and it’s capable of sample-accurate performance in a way that Pd or Max can’t really achieve, even with the Max scheduler in overdrive.
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.
Funny seeing Pd randomly on the front page of HN! I once (a LONG time ago) built a browser-based GUI for a remote Pd server: https://github.com/t3db0t/PureeData
When I was a masters student in the NYU Music Technology program, I Izard PD for a couple projects I'm really proud of.
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.
Pure Data is awesome. The UX could be better, but it showcases elements of what could be for visual programming languages.
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:
Puredata is cool. In reality it's a real time scheduler where the time for everything to be due is "now". Which works well. msp developed it for computers in the 1980s where resources were seriously constrained, so these days on bigger computers / handhelds you get a lot of computational bang for your buck.
Probably one of my favorite OSS projects to date. I'm not a musician at all but playing with it is a lot of fun. Just make sure the volume isn't set too high :P
I've dove into PD vs Max quite a bit the last few months, and I've found PD to be a bit... archaic in it's design and how it looks.
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.
There's a community, it's just very conservative. The problem (especially with PD) is that the community is hostile to anyone who says 'hey, this is great, but hard to use.' It was true >20 years ago when I first became acquainted with PD and even more so now. 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).
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.
> 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
> 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.
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).
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.
> 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.
> I've found PD to be a bit... archaic in it's design and how it looks.
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
The gui really needs its own theming if you use it a lot, and the header file that is supposed to be the stable api is... Limited. Thankfully the unstable stuff hasn't been changed in years so ¯\_(ツ)_/¯.
https://patchstorage.com/ has been making a pretty heroic effort at being a searchable hub for, pure data in the beginning, but now many.
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
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.