#192

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.

1 Like
#193

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.

http://write.flossmanuals.net/pure-data/introduction2/

1 Like
#194

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/

#195

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

#196

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.

1 Like
#197

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.

#198

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?

#199

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.

#200

isn’t it really just a small front end to :
http://deken.puredata.info/search?name=

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?

#201

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.

#202

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

1 Like
#203

Shrug. Maybe someday.

#204

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!

#205

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)

3 Likes
#206

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

#207

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

#208

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…

2 Likes
#209

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

#210

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)

#211

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