Puredata! (thread)


compositionally - Max/PD/Audulus are all great at the self playing patch - no question

compositionally I think that the pattern facilities in Supercollider is a hint of direction (sclang is such a mishmash of ideas & coding styles and hidden depth - such that every time I use it I can imagine the professional engineers that work for for me (writing enterprise stuff) making fun…). Tidal seems like a similar idea too but I’ve never managed to make that work on my computer. I have an abandoned python project along the same lines.

I’ve been trying to get my head around what that looks like in a graphical space - I did have an idea of a “sequencer space” where you could wire lots of sequencers together (probably do-able in all these languages BUT do-able is not the same as “easy and natural” - UX is important). The basic idea being that a sequencer (of whatever kind - step sequencer, generative etc) was an atom and you could wire them into systems, including non deterministic steps etc. Also you would want more than one to play at the same time. I guess the key thought I’m working on is “pattern as an atom” and work from there

As I currently am the director of a fast growing software company I’ve just not had time to explore that BUT I’m kind of hoping when I get some kind of exit to spend a lot more of my time exploring these ideas and others…


ooops wrong thread…


Coming in A4 :slight_smile: We’re up for any ideas, I think we’ll definitely make one with multiple playheads, but other than that I don’t know.


Tidal’s patterns are amazing and absolutely worthy of study.


A few people have made chainable sequencers in Audulus - you can use them to expand the number of steps and I believe they have pulse per step options and whatnot. Is that what you’re referring to?

I’m not sure how sequencing will work in A4 but it might benefit from a kind of separate view for sequencers. Great ideas all around!


So a couple of things:

“…is possible…” -> there is a big difference between what is possible and what is supported by first class workflow. If you give me a computer with a sound card and a C compiler, in time, I can make any music I want…

however I probably won’t get around to it. What I look for in my tools is different things that are each strong in areas I need for my music making

secondly - is Audulus the best place to add in a pattern language or composition facilities? I’m actually not sure about that - it’s strong at what it does. Perhaps a second tool that focuses on patterns - maybe with a similar UI is really what is needed, Don’t try to be all things to all people (I suspect this is what I find jarring about sclang - it has all these different levels of functionality. oddly I found COBOL the same “move number to register A” “CALCULATE COMPOUND INTEREST OVER 30 years” both similar level instructions!)


i kind of said the same thing regarding Audulus – it does some really nice things and sounds pretty damn nice but i see it as a patch/sound maker and i thought it would an ideal candidate for being like a MAX/Ableton M4L to bitwig type applicaton. I could see THAT being some VERY exciting new territory and benefit both communities


I don’t agree with myself from a while back, at least not enough to come up with a reasonable response. That said, I haven’t messed around much with the tools listed above since writing that.

Opinions are like toes, most everyone has ten and they wiggle when poked. I just made that up, feel free to put it on a bumpersticker and profit. I release it as creative commons.



interesting! yes very much the kind of thing I had in mind

I shall have a play


Just ran into context as well, the quick demo does a good job of giving a quick overview of what it can do. Looks quiet nice!


This is really cool! Thanks a lot for posting this!


okay he’s really made some amazing improvements from the versions i have.
I’m liking what i see


if you have any suggestions for other improvements or comments i’m sure the person that made it would appreciate the feedback.


Context has just been added to deken so now it’s very easy to install, and it comes with all the externals it requires.


I’ve been learning/using Pd on and off for the past few years, each time with a slightly different goal and each time getting a bit closer to being able to do the things I want with it, before getting frustrated or bored and moving on. This time round I’ve decided

  • not to bother with audio synthesis too much (now I have hardware for that!) in favour of focusing on live manipulation of audio in realtime and in buffers, something which computers actually seem to be a good tool for
  • not to force myself to thoroughly learn, understand and reinvent every tiny part of a patch
  • to use vanilla Pd but not to limit myself in terms of using externals to improve things
  • to be more creative about the physical interfaces I control my patches with, inspired mainly from what I’ve seen people doing with grids here and elsewhere

A few helpful things I’ve come across:

  • The CEAMMC library, from the Centre of electoacoustic music of Moscow Conservatory. This can be installed in vanilla using deken and has a bunch of well documented and organised utility modules, as well as some much needed beautiful UI elements like piano keyboards, range sliders, and envelope designers. From the gh repo it looks like it’s a complete distribution of Pd but it can be installed as a library in vanilla. A couple of things don’t seem to work, like the SoundTouch implementation, ironically the only reason I found the library in the first place.
  • The [filterview~] external, which unfortunately can’t be installed via deken but was easy enough to install and use manually. Additionally I made a little abstraction adding GUI filter mode selection and a built in stereo [biquad~] for quick use.
  • ofelia, AKA Pd bindings for openframeworks. A slick, well-documented, generally more modern version of GEM, which I always wanted to learn/love but never really managed either. I’m not so visual-art-inclined so I haven’t really managed to think up any interesting things to do with this, but if nothing else, the ability to use it to package Pd patches as standalone Linux/Mac/Windows/Android/iOS applications is definitely worth investigating!

I’m slowly building up to having a suite of Pd tools for live sample manipulation, something in the vein of @Rodrigo’s TPV and Solarference’s Max MSP performance suite (screenshots at bottom of page)

The most recent part of this is an adaption of the example pitch-shifting abstraction which comes with Pd, with “true bypass” added so it can safely be thrown in anywhere and won’t change the sound at all unless transposition is set to something other than 0:


That part is pretty strong with Pd im my experience. There’s just so much that just doesn’t work, or works in weird ways for unknowable reasons that it takes quite a bit of a mental effort to keep using it. How do all of you handle that? I’m sure I’ve wanted to just uninstall the thing and be done with it a dozen times. But there’s many things to love about it and that’s why I keep trying.

That was my conclusion as well. I’ve played with a bunch of Pd-based synths (and even tried to make my own) and while some of them are really well made, thre’s something about Pd and the way it forces you to do certain things, which makes them feel weird. Also Pd is full of bugs and glitches it seems, so you can’t expect things to just work.
Moving away from more standard synth implementations there’s a bunch of cool things like AUTOMATONISM which to me do make sense as a Pd thing and are actually quite fun to play with.
The thing though is, Pd really makes sense when you make your own patches and I wouldn’t be able to make a half-decent synth anyway :slight_smile:


What kind of bugs and glitches? I used pd for (seven?) years prototyping ‘stuff’ and I’m curious about what you mean.


I handle the mental effort required by following my motivation. I pick up Pd whenever I have a clear idea of what I want to achieve with it, even if that idea is “vaguely explore concept/technique X”. Then I stop whenever I lose motivation and go do something else, which inevitably ends up informing and developing how I approach Pd when I inevitably return to it.

This time round, those things were: building an Ambika and Shruthi (no need for conventional subtractive soft synths any more!), being inspired by seeing how people use grids to control live sample manipulation software, and realising how much more expressive my Pd use could be with interfaces like [filterview] available.

For example, Pd crashes on me if I plug in or remove an audio interface while it’s open. There are a bunch of undocumented features which work inconsistently and/or are buggy. There are tonnes of UI inconsistencies, limitations and irritations which feel like bugs when comparing it to something like Max or Reaktor.

I think one of the biggest factors leading to people seeing Pd as being buggy is that there’s a huge amount of DSP and Pd-specific knowledge required in order to make patches which actually sound good, which makes the whole thing feel glitchy and lo-fi until you know how to work around the clicks and pops.


Another thing I can recommend is “reading” good Pd patches. I’m currently working my way through the organelle patch library as a source of mostly well-written, proven patches. Automationism never really clicked for me as a thing to actually use, but it’s excellently programmed and I’ve spent a lot of time “reading” it, and have started to apply some of it’s UI conventions to my own patching.