#36

Last night I hooked up pd and Automatonism to my physical modular via an Expert Sleepers ES-8. Worked great! Automatonism doesn’t have a calibration tool like BEAP / Reaktor / Bitwig / Silent Way, but that’s not a show stopper IMO. Nice toolset, feels like a good jumping off point into further pd studies. Also - totally superficially, I like the aesthetic of Automatonism way more than Reaktor. BEAP is somewhere in the middle. Really dislike realism / skeuomorphism in computer interfaces. I like the Tron-like Automatonism vibe.

5 Likes
#37

I just wish I could put bends in Pd wires so they didn’t cross over controls. I realize this is my OCD talking.

5 Likes
#38

this is totally freaking me out as well, but I guess I’m an OCD case as well…

1 Like
#39

It depends which platform you started with. PD was my first, so I still find it really wrong looking when I see curved or bent lines in Max. :slight_smile:

2 Likes
#40

and anyway… you can tidy things up a lot by using send/return symbols in objects, and subpatches.

5 Likes
#41

Do sends in Pd suffer from the same order of operations (bottom up, right to left, but good luck with making sense of nested patchers) problem that they suffer from in Max?

I like writing code using text!

But Pd has awesome power, can’t deny that.

1 Like
#42

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.

https://puredata.info/docs/manuals/pd/x5.htm#s3

Huh?

2 Likes
#44

Indeed!

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.

2 Likes
#45

Mostly.

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:

3 Likes
#46

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.

1 Like
#47

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…)
(https://github.com/catfact/audio-externals/tree/master/fpu)

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.

2 Likes
#48

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?

1 Like
#49

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.

5 Likes
#50

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?

1 Like
#51

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:

4 Likes
#52

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:

6 Likes
#53

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


image.jpeg3024×3024 1.49 MB

#54

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.

3 Likes
#55

This is worth repeating a few times over /

Always
Use triggers

Always use triggers

Always ! Use ! Triggers

6 Likes
#56

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.