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

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

2 Likes
#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.”

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

2 Likes
#68

This is absolutely true, but I think it makes sense if you look at the design intent of these languages. Max and PD both came from the work of Miller Puckette at IRCAM. His original use for the language was to create a generative improvisation partner for live performance… auto accompaniment using complex algorithms, as I understand it.

PD and Max excel at specific things, which doesn’t really include determinate composition. What they are really amazing at is taking external input (audio, sensors, network data, video, etc) and reacting to it. They are amazing for building generative and indeterminate systems that listen and respond to themselves and others, and for integrating various media and control signals. They are also inherently real time, and visualize the structures of the language rather than code in a procedural way.

Maybe you could say that PD/Max is computer music’s “west coast” to csound et al as “east coast”? :slight_smile:

6 Likes
#69

It’s funny because one thing I never really got into is C-Sound (despite trying to), and the reason is that it was very linear in its nature, mainly focused on writing a piece of music and then having the machine play that for you, which didn’t really resonate with me much.
I guess I like things to be more like an instrument that you play, and Pd is great for that (at least as far as I can tell!).

2 Likes
#70

It does require controllers or something along those lines if you want expression beyond sequencing and don’t want to use a traditional instrument for input. A mouse just doesn’t make for a great instrument. I also find Pd to not always be the most legible environment, which doesn’t make for great performance ergonomics.

But get the control/generation/input away from the computer (use Pd in a more headless fashion) and the score (if you want one) lives outside the DSP environment. It could even be (gasp) on paper. This seems to be how Pd was intended to be used.

2 Likes
#71

Yeah, legibility is not a Pd thing indeed! :slight_smile:
how I am solving it right now: I pack things into subpatches and use lots of send/returns to connect them to a GUI that will collect all the main controls.
I need to look into GUI plugins, Vanilla doesn’t offer a lot beyond faders checkboxes and bang buttons…

#72

Yeah, this is exactly it. The system was always intended to be used “headless”… you setup the system and then you play other things into it and it responds. That was the original design intent.

2 Likes
#73

One thing that changed how I viewed Pd was when I read about state persistance. From the docs:

“Among the design principles of Pd is that patches should be printable, in the sense that the appearance of a patch should fully determine its functionality.”

Like you’re saying, it does not seem conceived for large patches with a lot of hidden dependencies and state.

The Pd manual in itself is great. So succinct and to the point.

Oh, and have you all tried out the recently added moog filter bob~ in Pd vanilla?

3 Likes
#74

well… it does succeed in this to a certain degree. the wires not being bendable being the main obstacle.

Oh, and have you all tried out the recently added moog filter bob~ in Pd vanilla?

Need to try that! didn’t even know about it, so thanks for the heads up!

1 Like
#75

Maybe you could say that PD/Max is computer music’s “west coast” to csound et al as “east coast”?

oh hell no. no. sorry. you did not just tell me that MIDAS is ‘east coast.’ :slight_smile:

not to go too far down some rabbit hole, but “determinate” is a red herring here; i’m not talking about playing back a fixed sequence of notes (well i guess i used that as a trivial example) but, MIDAS and csound and sc’s patterns give you not just a piano roll, but an environment for manipulating time structures, with arbitrary parameterization (midas INQUIRE, &c), at a high level of abstraction (e.g. directly transposing / reflecting / stretching / repeating a sequence or subsequence), in realtime or as close as the designers could feasibly get at the time of the design. interesting forms of compositional indeterminacy flow directly from this.

sorry to harp on MIDAS, but it’s an interesting example, on my mind lately. it’s trivial to implement parameter feedback within a MIDAS program. it can be very hard to predict the output from the program text…

nothing could be more “west coast” as far as i’m concerned! (but i’ll admit that i can never quite predict what people will mean by this - no no, please don’t tell me.)

my rather spontaneous comment happened because i hadn’t quite realized (or had forgotten) that i do miss having some arbitrary pattern generation tools directly in pd (even though i am mostly not that kind of composer.) so maybe that would be a nice thing to think about? as it is, when i pull out PD to play with signal graphs (or because i am using its C API to try something) i often end up hooking it up to some other system for control. or i wrestle with qlist and messes of delays. silly!

alas, i cannot get PdLua to compile (yet) and so still have no real idea exactly what it does. seems nice to have Lua in there but a more specialized musical language could be nice too.

yes, OK, miller had specific intentions, maybe PD was conceived at last partially, maybe mostly, as a “stateless” (yeah right) consumer of note data. i’m not so sure that’s the case, but so what? it has “noteout.” it’s a useful framework for many musical applications, and is uniquely extensible. that’s a good thing!

</rant>

2 Likes
#76

I’d love to see macro scale parameterized pattern generation + piano rolls in Pd.

Seems like a worthwhile project to add to the list of projects I’ll get around to sometime during my 4th or 5th reincarnation…

#77

I’d love to know how many people Automatonism brought to Pd. I’ve been loving it. It’s been a great intro to PD in some ways. I started a little bit ago with Xodular and Ecosystem. love Pd. Made it a goal to become proficient in it.

4 Likes
#78

BTW. Pd Extended is abandoned now, right? And OSC support is in vanilla?

Someone should update the pd grid studies pages … :slight_smile:

4 Likes
#79

Yes, Pd-extended is deprecated in favor of
http://puredata.info/docs/Deken

1 Like
#80

I’m in the same boat right now, but with much less experience to offer as example. I’ve been hardware only for a few years, just using a computer as a glorified tape recorder. Now I’m working on a hybrid Eurorack / Laptop setup and have been looking at software. My issue with puredata (and Max, and Reaktor and Audulus) is their core goal is to create sound with composition as a tacked on feature. I’m pretty sure I’m going to end up with CV-toolkit as my preferred hybrid tool. It follows the modular paradigm but adapts it to a computer interface (no draggy cables, a matrix system that’s way more practical for a keyboard and mouse) plus refined MIDI & OSC support. It’s not as deep as puredata, but I think it’s a better target for what I’m going for. It’ll give me a whole lot of logic modules that I can use to manipulate sequences over time. It’s like buying a $2000 box of 4hp modules for $50.

That said,

something that lets you easily bake stuff together like automatonizm i find myself just creating short loops but never exporting them

Is a problem I’ve had with eurorack modular in general for a while. I think I’ve come to terms with it, using a variety of techniques to give me time to transition between patches (a sampler in the mix is my go-to here) so I can keep a flow that feels improvisational without getting stuck on a single loop. CV-toolkit is going to extend my ability to keep things interesting.

Anywho, this is a bit of a tangent, not really about puredata, but about a general category of tools that are awesome at 8 bar loops, not so awesome at pulling together a complete piece.

3 Likes
#81

Watching Suzanne Ciani last weekend woke me up to the fact that this is a bit of a source of stress for nearly everyone who attempts longer pieces on modular gear. I dunno, maybe that’s not the right word. She never looked stressed, but there were moments when she was moving very quickly to get everything she wanted done in time.

1 Like
#82

There’s also the very cleverly named purrdata. It builds on the linux laptop orchestra distribution of pd which built on top of pd-extended. It’s big innovation is ditching tk as an interface in favor of a html5 interface. Some legacy libraries aren’t portable because of the tk bits, but I confirmed Automatonism is (at least based on the half hour of testing I did).

1 Like