#171

I’ve run Pd successfully on small systems even less powerful than an RPi 3.

#172

Yes
I currently have
AM
FM
Granular [ALL FLAVORS]
Spectral [Erbe]
PitchShifting [Vetter]
MIDI [Fluidsynth~}
Gendy
Sampling
Csound
rtcmix~
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!!!

9 Likes
Raspberry Pi for music
#173

Cool! I gotta get this going.

#174

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 :slight_smile: 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
these include:

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?

EDIT:
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.

3 Likes
#175

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?

#176

Yes, with regard to RPi.

4 Likes
#177

But can it load on a Raspberry Pi Zero? Asking for a friend (actually me).

#178

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)

#179

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.

#180

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.

2 Likes
#181

Oh that’s what you mean… I stumbled into this one some time ago:

#182

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.

#183

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.

#184

I think this is the starting point you’re looking for, explains how to surface controls at the parent of a re-usable subpatch:
http://write.flossmanuals.net/pure-data/graph-on-parent/

1 Like
#185

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.

#186

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)

2 Likes
#187

Yeah, I’m decent enough at C/C++ but not super super interested in writing a C external for wiring up the display (this would be using a Push 1 anyway). I appreciate all the suggestions, my initial question was out of sheer laziness. I’ve already got a few things that work with an m64 to do isomorphic things with puredata/whitewhile, it was more a “if this exists, I would use it” type of problem. Your organelle project looks dope! I’ll definitely keep an eye on it.

#188

oh, you referenced the Push 2 spec in your post above… so I assumed you were talking about the Push 2.

the Push 1 is completely different (and that spec does not cover it) , the Push 1 uses Sysex for driving its display, so you can do that from within PD… you can find the details of the sysex with a simple bit of googlefu
No idea if anyone has done anything for the Push 1 and PD… I know there was something available for Max.

#189

oh, you referenced the Push 2 spec in your post above… so I assumed you were talking about the Push 2.

My bad I should’ve been a bit more clear on that. Going off of https://github.com/Ableton/push-interface/issues/5 looks like a spec similar to the push2 one won’t be happening. http://pushmod.blogspot.com/ has some stuff, I’ll search around for a sysex helper. I feel like there must be some prior art for puredata that’s push1 specific.

#190

Is there any way to use deken from the command line?