Puredata! (thread)


Apparently, it sends signals in the order you patched it.

In Max/MSP, if an object’s outlet is connected to several destinations, corresponding messages are always sent in right-to-left screen order. In Pd, the messages are sent in the order you made the connections in. In either case, in situations where you care about the order it’s appropriate to use a “trigger” object to specify.





The other superpower of PD/Max/etc is that it’s real time. You don’t write some code, then compile/run it and see what happens. It all happens while you’re coding. Much more like working with a modular synth than coding in many ways.



But when you talk about order of operations depending on order of patching or position on a canvas, these kinds of concepts are distinctly located in the realm of software (and considerably “weirder” to reason about than more traditional coding concepts). As for compilation, not all text-based coding requires that! Interpreted languages are a thing. Live coding is a thing.

And my gripes about Pd’s quirks are just gripes. It doesn’t stop me from using Pd. I’m a designer. I see flaws and have urges to correct them. It’s super irritating to myself and everyone around me! Sorry about that! :smiley:


Yep, that’s all true :slight_smile:

I’m the same way in terms of wanting to fix everything. And totally agree that the patching order thing is strange. I’ve rarely run into a situation where it really mattered, and using triggers is way more predictable anyway. But yes, it’s a strange quirk that requires work arounds/best practice to manage.

Max has fewer of these types of quirks, but it’s also not free or OSS.


order of operations depending on order of patching or position on a canvas

Always Use Triggers. applies to max too…

oh! i made a fun signal external this week. it’s a weird nonlinear string thing. (brian will remember…)

to be fair to max, while in some ways the SDK is much more painful (for example, i gave up on setting up an xcode project from scratch, and just forked the max-sdk repo)- it does some things better - like, it’s relatively easy to make inlets that can accept either floats or signals. haven’t figured out how to do this in pd yet.


wow! lotsa great stuff in this post!
I’ve been using puredata for sometime as well, still love it, and still I feel I have tons to learn, the possibilities are infinite!

I often use it to model analog circuits, very interesting as it lets you try any signal routing architecture, all at your fingertips, immediately! It has some difficulty simulating recursive and non-linear responses, usually found in analog equipment, but you can use buffer-sized delays to be able to loop, and hyperbolic tangent functions to simulate silicon saturation.

Always wondered of making a puredata-based only liveset, raspberry pi, some faders and a trackpad, or graphic tablet (to be used without pen), or even a tablet via OSC.

Anybody here ever played a gig with puredata only?


I play out with Pd all the time! I’ve been using it for years on my laptop, tho’ recently I’ve been experimenting with PdParty on an old iPad. I just recently played a gig in Helsinki where I played guitar into a patch on my iPad using an iRig interface.


oh yeah of course! pdparty on a tablet! no need for a pi, actually! I’ll give it a try ASAP! Thanks for sharing the idea! Do you have any recordings of your shows?


Just about everything here https://acompanionofowls.bandcamp.com/ and here https://soundcloud.com/a-companion-of-owls has been touched by the hand of Pd! :wink:


i have been having great luck with Organelle. It makes pd immediate for me again and i am overjoyed. I think i posted on this earlier but it’s paying off. I have been basically living pd programming for the past few weeks – feels like grad school again :slight_smile:


:slight_smile: plz feel invited to join us at the coffee klatch
and drop whatever you got rockin’ in puredata at the moment! thx


I’ve been using Automatonism for this sound installation and it has saved me so much time compared to patching the same thing from scratch. There’s a bit more overhead, but not enough that its had any impact.

I would love it if the state saving was a little more transparent so that I could add my custom patches to the state when I combine my own elements with theirs. I’m going to dig into that a little more when I have time.


This is worth repeating a few times over /

Use triggers

Always use triggers

Always ! Use ! Triggers


I haven’t totally figured this out, but I did catch some interesting shenanigans with the phasor~ source code here: https://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/d_osc.c#l62

It uses a dummy var to hold the scalar value, and the inlet’s behavior corresponds to the object’s arguments. I don’t think it’s totally “either/or” (haven’t fully tested it out), but it’s at least somewhat multi-purpose. I think the particular trick is the CLASSMAINSIGNALIN at line 118, which (I’m guessing) promotes x_f from a scalar to a signal in the _dsp funciton.


indeed, here’s what i got from the “pd-externals-HOWTO” document

Signal classes that want to provide signal-inlets have to declare this via the CLASS_MAINSIGNALIN -macro. This enables signals at the 1st (default) inlet. If more than one signal-inlet is needed, they have to be created explicitly in the constructor-method. Inlets that are declared as signal-inlets cannot provide methods for t_float -messages any longer. The 1st argument of the macro is a pointer to the signal class. The second argument is the type of the class’s data space. The last argument is a dummy-variable out of the data space that is needed to replace non-existing signal at the signal-inlet(s) with t-float messages.

i just don’t know how to extend this to have multiple signal inlets that can also accept floats (as i can in max.) would love to see a pd extern that does this. maybe it’s not possible and the “right” way is to just use messages for non-signals. it’s a very minor problem really but would be nice to build externals that function identically in both environments.

or, uh, i guess i could just try and actually grok that macro.


do report back if you ever experiment with that! pretty handy tool :slight_smile:


Anyone using Automatonism via DC audio interface to control eurorack? I’ve experimented with it, it works fine for things like LFO, but without a calibration module I’m not sure how to use it as a quantized sequencer. I’ve only played around for a few hours, so this might be a premature question, but could use some encouragement that this is a good path, given the existence of Reaktor Blocks & CV Toolkit.


Haven’t done it yet, but it’s one of the things on the TODO list…


Maybe I’m going about it the wrong way? Maybe the calibration module isn’t necessary? I don’t have a calibration module in my rack, I just tune to the CV. Hmm. Something to think about.


Yeah, confirmed. Tune the VCO to C4, everything else works pretty fine. Slope / envelope generators can be a little fiddly with voltage levels unless you crank up the depth a bit, but otherwise had a successful evening of knob twiddling. Crappy video proof (one of these days I’ll learn how to get good sound into my phone, but for tonight, figured a simple video was ok),