Pure Data implementation experiment (original post)

Hey! First of all, thank you for the work you’ve done on this fork! It ran great with only a little configuration. 

This is going to be a bit of a long post so sorry about that...

I’m building two samplerboxs, one for my brother, and one for myself, using 3B+, a hifiberry clone, and (eventually, haven’t gotten there yet) oled displays, with the idea of integrating an arduino for hardware midi controls. I’m just finishing up a midi expansion console for my analog synth, so I already have working code for that (...with an lcd touch display as an xy pad, and 21 pots, 12 of which are nrpn messages... way more complicated than I planned... the samplerbox controls shouldn’t be as complicated)

Please keep in mind that I’m not really a programmer and I have’t really used linux since I was a teenager   but I get along pretty well with enough examples in front of me!

So I have (maybe) a bit crazy of an idea of running a pure data patch alongside samplerbox.

Pure Data, for those that don’t know, is an open-source Max/MSP-like visual programming language for artists and musicians, made by Miller Puckette, the original creator of Max. You can build digital synthesizers, audio effects, and a thousand other things in it. Pure data running on raspberry Pi is currently being used on a few boutique commercial instruments, like the critter and guitari ‘Organelle’, and I believe a few eurorack modular synth modules. 

It can be a little confusing to get started in, but fortunately I found Martin Brinkmann’s website, who has made a large repository of instruments and patches, including a set of modular units for easily putting together instruments (the ‘virtual(virtual)devices’ file), lots of fun and a much easier way to get started in pd!

http://www.martin-brinkmann.de/pd-patches.html

It’s important to add to the patch

[loadbang]
|
[del 1000]
|
[;
dsp 1(

That’s a pure data object that says “loadbang” (which loads a function at startup)

Connected to
 
a pure data object that says “del 1000” (1 second delay)

Connected to

a pure data message that says

“;
dsp 1” (turns audio on)

I can include a picture of what this looks like later... and maybe the patch I’m currently trying to run (fm synth, but it’s really just a placeholder)

My basic idea is to have a digital synth alongside samplerbox, sort of as a paraphonic voice, so that I can do things like create pads and swell sounds behind sampled piano, but it could also be used for custom delays, reverb, modulation, or say something as out there as using samplerbox as the audio source for granular synthesis. 

Honestly I don’t know if the Pi 3B+ will have enough cpu head room for both, if not it might be something I try again when you’ve finished the Pi 4 update... top says it’s using more cpu than the samplerbox.py script, but total cpu is still below 40%

Basically how things should work is by connecting samplerbox’s audio out to pure data’s audio in using Jack audio connection kit, and then out to ALSA (I think? or maybe again to jack and then alsa? It was late last night when I got to jack). 

so far I’ve managed to install pure data and jack, and add a script that boots my patch at startup (using various tutorials online), but I have yet to figure out how to configure jack via command line, and I guess I’ll also need to stop samplerbox from connecting to alsa... (so far I haven’t been able to actually test my patch on the build because I’m having trouble getting audio out, but it’s definitely running, I can see pd in top)

I’ll walk you all through the steps I’ve gone through so far
Pure data and Jack both just installed with apt-get

apt-get update 
apt-get install puredata
apt-get install jackd

 (make sure it has that d, had a hard time finding the proper name in the documentation, but it was also 3 am last night so I’m probably to blame    without it you end up installing some CD ripping software)

I then discovered that there’s a bit of an issue with pure data recognizing my midi keyboard (it lists it as an audio device??), some other people had this issue and fixed it by installing aconnectgui (booting it without GUI just with the command ‘aconnect’), and connecting pure data to the new virtual midi port

I then made a script (following the instructions on https://guitarextended.wordpress.com/201...pberry-pi/ ),

But included:

jackd

aconnect

and modified the pd line to something like (sorry, I don’t have it in front of me, and I tried a dozen combinations):

pd -nogui -jack -audiodev 1 -alsamidi -mididev 20 -open /your/patchlocation/puredatapatch.pd &

(Not sure that midi port number (20) is stable... could have sworn it was 1 at one point... if not I might need to figure out some kind of script or if function to identify the port and put that into the pd line...)


Currently can’t connect to alsa audio because it’s already busy with samplerbox

so if anybody has any experience with jack, or configuring pure data, or is just interested in trying this experiment out with me I’d love to hear your thoughts!


Sorry again for the huge first post 

Hi bbishop,
Good to hear you got it working without issues.
PD sure is a valuable idea, so here my five cents:

When using samplerbox playing fast and/or using chords plus effects, you'll see the CPU grow far above the values you mention. The PI4 ambition isn't just for fun so to speak.
So adding another sound generator might choke the PI when using it for more than small functionality tests.
On the other hand: if PD has it's CPU unaffected by way of playing (samplerbox has to fiddle with wav data at note on/off), it could result in a working setup.

As mixing sampled sounds with synthesized sounds gives very nice results indeed (and is used on stage often, be it it with a "real" instrument feeding it's signal also to a midi synth), it's on my wishlist too - ok, far away future that is 

In order to enable that in a modular way, the brandnew release now supports midi-through. So the extra synth(s) can be fed by the same midicontroller / keyboard by throughputting the midi signal to the extra microcomputer(s) like PI, ESP, etc.
Doing this can also ease the volume balance between the various sounds.
If you're not afraid of DIY, you can use the serial ports to connect them directly and keep it all in one enclosure.

But one way or another: have fun!
Hans

Hi Hans!

Thanks for the reply, I wasn’t able to respond till I got home from work, but that gave me plenty of time to think things over.

Actually testing the limits of samplerbox by cranking the chord and arpeggiator on my controller was the first thing I did when I got it going, very pleased with what it was capable of!
I’m probably going to reduce polyphony to lower the chance of peaking no matter what, but I’ve been using this as a bit of a benchmark as I test things out. 

Until I have the audio configured for pure data it’s hard to tell if it’s actually working, but with the midi controller properly connected (or, as far as I can tell...) and testing the limits again samplerbox seemed to peak at the same range while pd stayed static (maybe moving 1-2%), from what I can tell it’s the overall complexity of the pd patch that determines the cpu it demands, and not what midi is currently making it do, so that’s promising! Obvious limits of the type of patch I can build but it would also make testing a lot easier.

 I understand that it’s the sustained release of notes layering on top of each other that causes the cpu peaks in samplerbox (all those wav files playing on top of each other), I believe you’ve mentioned elsewhere that reducing polyphony using reverb to simulate sustained release is more efficient. In pure data it might be possible to have an envelope follower control the level of reverb (increase it at the end of a note), for a more realistic simulation, but pd might end up demanding too much. 

After more reading up today (when I should have been working   ) I found out that alsa loopback (instead of jack)might be the better option for routing audio between the two programs, I should be able to just set the audio-out in the samplerbox configuration file to the virtual alsa port, and same with audio-in in pd... I’ll find out later, I’m going to load the new OS build and start fresh!

Using two boards is definitely a possibility, although having a nice way to power both in a single case becomes a bit of a problem. My heart is not set on this all working on one board, but if it does it greatly influences my case design and the number of hardware controls I include (I work as a sign maker/engraver/CNC operator so custom case building is more of my area of expertise).

 I think if it ends up requiring two pi’s I’ll just make a separate instrument just for pure data, which I might do anyways, but leaning more towards as a “music computer“ like the organelle or op-1 (but with more knobs and no built in keyboard)


Also in my research today I found this compiler that converts pure data files into more efficient c/c++, which might be a necessary step to keep it resource friendly.

https://github.com/enzienaudio/hvcc

https://www.rebeltech.org/2018/09/12/com...-compiler/

a little update and a little progress...

(appologies if this is getting annoying)

I did what I said and started fresh last night, flashing the latest image to my sd card 
(btw the samples partition was still not recognized by windows, not sure if thats an issue on my end, I used the raspberry pi imaging software so maybe it's that, or maybe I caught a bug!)

tested my initial config to make sure I have the audio card working

wrote a new (simple, only uses 2% cpu) test patch and copied it over, reinstalled pd, started alsa loopback and edited configuration.txt to set the correct (virtual) audio device,
wrote my little boot up script, which goes as follows:

Code:

#!/bin/bash
# This script will start Pd in nogui
# mode and will open the patch
# named "boottest.pd"
echo "Starting Pd..."


#start aconnect, list devices to double check midi device numbers..
aconnect -l

#start loopback to create our virtual soundcards
modprobe snd-aloop

#list alsa devices to double check that loopback is on, also used for configuring samplerbox's audio out
aplay -l

#launch pd with our file and settings, and list devices to check our devices (make sure audio dev matches what pd says what num loopback is.. which doesnt seem to match aplay listing,
#and that midi matches what aconnect says)
pd -nogui -r 44100 -alsa -audiodev 7 -audiobuff 80 -blocksize 64 -channels 2 -alsamidi -mididev 20 -listdev -open /boot/boottest.pd &

rebooted, but still no audio, pd is giving an "unable to sync A / D / A ". it was getting late again so I called it quits for the night.

I'm thinking I'm not fully grasping setting up loopback, or I have audio settings wrong in pd, but still feels like progress!

for those that are interested I'm including a copy of my patch and a screen grab, its just a modified example from the help directory. turns the audio on and plays a tone on startup, as well as audio in for recieving the samplerbox signal. midi transpose and a volume cc, so I'd know immediately if either audio or midi is working.