Puredata! (thread)


deken is a package manager for pd-vanilla. I guess there’s only a TCL implementation, so I suppose that means headless Pd users on RaspberryPi will need to either use their distro package manager, or compile/install manually.


Found this puredata manual during some searches - hadn’t seen it before, and I’ve had a lot of issues finding puredata docs that I like. It seems really up to date and organized in a way that makes sense to me. I couldn’t find a link to it in this thread, so figured I’d drop it in.



Oh yes, that’s of the best manuals for Pd I have found so far.
This book is also very good imho: http://www.pd-tutorial.com/english/


You could just remote into the machine using VNC or something. I’ve been using that for my pisound box. Works pretty well.


Then you have to install graphics packages. I don’t want to.

I came to the conclusion that supercollider is more aligned to my goals for this box.


have 2 images (different SD cards)… one for headless, one not… then just transfer binaries across from one to the other (via card reader or whatever)

I quite like having different images for development /release… partly because its useful to have all sorts of tools including X for dev/debugging etc… (i do similar with virtual machines) , also means you have a backup of sorts.


Are you concerned about system resources being taken up by graphics? That’s interesting I hadn’t considered that. I wonder are those resources allocated and in use even when a monitor or Remote Desktop isn’t in use?


Honestly? It’s because this SD card I happen to be using is on the small side.

But it’s also an objection on principle that a package manager should not require a GUI.


isn’t it really just a small front end to :

so you dont have to use the tool…

you can quickly create throw together a script to do wget | grep | tar … which’ll do the same thing - no?

if you don’t need to automate it, basically the wget tells you what you what you need to know anyway and you can just cut n paste the url you need

or is deken smarter than that?


deken is pretty dumb. And you’re right that a bit of hacking will result in a script that does the same thing.

Hacking that whoever made deken probably should have done, but I digress.


then create it, share it , open source it :wink:


Shrug. Maybe someday.


isn’t this also the case with supercollider to some degree? think I remember getting really stuck setting up superdirt till I ran the GUI once, after which the command-line tools worked fine!


i don’t know about superdirt. but it’s certainly possible to write SC code that makes assumptions about the client (cocoa, Qt, &c) and that will break with just the terminal client.

in general though, the SC “package manager” (Quarks) just works inside of sclang:

Quarks.install("UnitTesting"); - just a thin wrapper around git really

(sorry OT)


Go SuperCollider :slight_smile:

What are your plans for the box? Do you intend to run the scsynth server solely on the pi or sclang too?

Just curious


Going off topic, but it’s running sclang via emacs sclang mode and sclang-extensions.


steering this sc tangent gently back toward the original topic … my thinking is pd is a good tool to embed monome grid ‘controller apps’ (recent efforts/progress in this direction), whereas sc is very interesting for softsynths, e.g the DX7 clone posted in FM synthesis…

So what’s the best way to make sc & pd communicate? OSC? embed sc in pd? someone has already been down this road I’m sure…


I really like this train of thought. OSC seems like an obvious candidate for interconnection.


Puckette seems to regard it as bloat judging from the docs, so vanilla’s OSC support seems a little scrappy. I may as well reinvent the wheel & bundle a more intuitive OSC object with a monolithic ‘grid apps’ external. Liblo is my only dependency so this doesn’t seem like total madness (I don’t want dependency on deken-provided packages or similar for the reasons discussed earlier in this thread)


I have to admit that I have a hard time grokking the Pd design philosophy. For example, is it meant to be used headless? Puckette sometimes seems to indicate it is, and the lack of a “nice” GUI seems to support this assertion, but then things like deken come along that introduce a GUI dependency for very basic functionality. So, I often have cognitive dissonance around Pd. I really want to love it though. And seeing Pd in use in various embedded scenarios only enhances this desire (as well as a desire to keep it headless!)