Puredata! (thread)


#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?


#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.


#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?


#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:


#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:


#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



#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.


#55

This is worth repeating a few times over /

Always
Use triggers

Always use triggers

Always ! Use ! Triggers


#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.


#57

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.


#58

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


#59

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.


#60

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


#61

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.


#62

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),


#63

one this i’ve struggled with in general is putting together something that amouts to a performance in graphical languages like puredata. i’m not sure if it’s just a lack of discipline, but even with something that lets you easily bake stuff together like automatonizm i find myself just creating short loops but never exporting them or building upon them. anyone have any ideas on how to target concentration to get something more structured out of something like this?

not sure if i should approach it like any other instrument (like how you would use the organelle with pd) and imagine just one part of a bigger whole or if the “kitchen sink” approach is even feasible.


#64

y’know, now that you mention it, i think i have always felt this limitation with max (which i used heavily for a while, lo these many moons ago), and pd is the same - both only give you the most basic tools for building and manipulating large scale time structures: basically, qlist for a fixed sequence, or rolling your own abstraction for more dynamic structures (and dealing with the attendant complexities of resetting / recalling / mutating / changing time base / &c). so one tends to make a single effect, or bank of effects with realtime controls, or simple preprogrammed timings.

compare to supercollider, csound, MIDAS et al, which give you powerful compositional tools and modes of interaction a priori.

to the point where many users resort to embedded javascript in max, or… well i don’t know what in PD really. is there a lisp interpreter object or something? maybe i should make a Lua external, with bindings to timing functions? that would be handy.


#65

Just googling around, found this CL object which apparently leverages some Lua bindings?

Agree that scores are hard in max and kind of unknown in Pd.


#66

oh, hey
https://puredata.info/downloads/pdlua

“dammit, PD.”


#67

Pd is nice. I patched alot some years ago. I used pd vanilla. I like its simplicity.

Max feels a bit bloated compared to pd. If Max is the C++ of data flow languages to me Pd is C.

I posted a reverb patch to the pd-list some time ago. I just uploaded it to github:

The algorithm is based on a paper by Jon Dattoro. I found out later it had been included in rjdj ( https://github.com/rjdj/rjlib/blob/master/rj/e_platereverb.pd ) which made me happy.

I think it easy to reason about asynchronous processes in data flow languages. In the end, though, I found refactoring to be a hassle. Nowadays I’m mostly using SuperCollider.