I’ve added it to my path by default, you might need to add an [import cyclone] somewhere in the patch.
Recent adventures with Pd-vanilla have caused me to repeatedly arrive at this page, so I thought I’d share it in case it’s helpful to someone else:
thanks a lot, very useful!
I’m curious about the pisound as a vehicle for running headless sound patches on a rPi easily. Sample manipulation, granular synthesis, etc. Is the pi a viable platform for this kind of stuff?
Anyone have any experience running pd on pi?
I’ve run Pd successfully on small systems even less powerful than an RPi 3.
I currently have
Granular [ALL FLAVORS]
LADSPA plugins [C++}
All working on a headless raspi3 i am using an both a built in system and an external soundblaster card for audio
Mirror installs on arch linux
it’s a pd renaissance!!!
Cool! I gotta get this going.
Im looking to create some pure data externals for a number of platforms, including mac/windows/linux (arm,x86_32 ,x86_64)… including bela, rPI etc.
Ive created max externals before so hopefully not too painful but I’m a bit confused about the projects setup. with Max, Cycling provide a template, but for PD, Im seeing that there seem to be multiple template projects for building
- Makefile supplied with the pure data install (doc/6.externals/Makefile)
- svn Makefile template ( https://svn.code.sf.net/p/pure-data/svn/trunk/externals/template )
- pd-lib-builder (https://github.com/pure-data/pd-lib-builder) , as used by https://github.com/pure-data/helloworld
as i say, my aim is for something cross-platform and currently ‘supported’/used by PD projects…
seems to me pd-lib-builder is the most current?
I guess, Id also like to be able to perhaps push to deken later… but currently I don’t know much about that.
also how do i supports multiple arch… e.g. i see some are naming linux externals as ext~.pd_linux, but thats not going to work with when i have 64/32 x86 and arm linux binaries, similarly, are macOS externals always universal binaries?
thanks for any pointers…
btw: in an external (C/C++) , whats the simplest way to get the sample rate?
for now I’m going pd-lib-builder, which ive also forked to add ‘bela’ detection for. (I’ll submit a PR once complete)
sample rate, easy t_signal.s_sr = sample rate. (m_pd.h has lots of useful stuff in it ;))
so now got my first external running on both macOS and Bela.
… its pretty similar to the max external api, so once I worked got over by PD issues (Im a total newbie at PD) , was pretty straightforward.
anybody had any luck running monome on the pi? i’d love to get going with grid studies on pd.
also, who wants to get monome-sum ported to pd?
Yes, with regard to RPi.
But can it load on a Raspberry Pi Zero? Asking for a friend (actually me).
anyone have experience with Purr Data?
how is its stability? and compatibility? (compared to vanilla PD)
it seems attractive, as its actively developed, and comes with a good set of base objects.
can I run the patching GUI on a different machine to the PD engine?
e.g have the patch running on a rPI, but using the GUI on a mac/windows machine to alter/interact with that patch, as you can with something like supercollider.
(I mean natively within PD, I know I can run a remote X session, but thats not ideal for a few reasons, included extra cpu load on the rPI)
Purr Data is a bit like Pd extended, in the sense that it comes pre-loaded with lots of externals. It also has a couple of additional benefits like unlimited undos and a slightly more modern GUI (do not expect anything radically different, but having zoomable windows is nice).
The downside of Purr Data is that it’s a ~250Mb install vs. 17Mb for Vanilla, and you might not need most of the externals it comes with.
Also if you plan on running patches using libpd or anything else that requires vanilla you might run into troubles. Afaik Purr Data will not tell you if a node is relying on an external or not, so you need to check stuff manually.
Never tried, but that’s what OSC is for, isn’t it? though you can use MIDI as well I guess.
No, that would be to allow remote control of a patch.
I want to do the patching remotely - so a bit like supercollider - where the engine runs on one machine but the ‘patching interface’ runs on another.
It looks like purr data is separating engine from patching interface, and using the ‘right tech’ , but looks like it doesn’t yet take it to the next level.
Oh that’s what you mean… I stumbled into this one some time ago:
Does anyone know if anyone has released ‘helper’ patches for using the ableton push with puredata? I poked around online for a bit, but couldn’t really find anything and I don’t really want to try and write my own scaling to make the keyboard isomorphic.
I am glad this thread has had a bump. Playing a lot with automatonism (just on pc) and adding my own custom bits onto it. really enjoying getting into something new. Not sure how to go about making my own patches into automatonism modules. Also plan to get a bela shield and make some kind of noise machine. though i do have a half built axoloti machine on my bench that i should make something of.
Any links to any resources appreciated.
I think this is the starting point you’re looking for, explains how to surface controls at the parent of a re-usable subpatch:
Ah yeah, I was looking for someone that already had made a subpatcher. Ableton has pretty great docs here https://github.com/Ableton/push-interface/blob/master/doc/AbletonPush2MIDIDisplayInterface.asc I just don’t have enough free time to actually do the leg work right now.
the display cannot be accessed from midi, basically you have to write a C/C++ external so that you can communicate at the USB level.
I’m doing some work in this area at the moment, so you can keep an eye on this.
note: not quite sure which platform your using, my priorities are Mac and Linux (ARM and x86), so whilst I’ll no doubt do windows, its not really a priority.
if your just after lighting up the pads/and getting notes, that can all be done via CC/note on/note off messages - and is pretty straightforward.
developing isomorphic layouts is pretty trivial, you just convert the note # into x, y, then the new note number = base + (x * row offset) + y … if you want to add scales (rather than chromatic), that gets a bit more complex as you need to use the new note number to index into a scale array.
anyway, i’ll be doing this all in the ‘system’ I’m developing, but just can’t commit to when it will be available.
(my approach is to run a separate app, which is communicating with a PD external, this is because I personally don’t want the USB code to run inside the pd process… though no technical reason it can’t)