#2

There are a bunch of different ways to do this. Raspberry pi, bela.io, Hoxton OWL, Qubit Nebulae, organelle…

Anker makes great USB hubs.

#3

thanks a lot @jason22! this is what i was hoping for / afraid of :slight_smile:

i am planning to use the “system” in a modular / eurorack environment, but considered to simply hook it up to my endorphin.es shuttle control (using midi only, to keep my hands of off dsp / voltage conversion and other things that would dig too deep).

can you hint me in a direction as for which of the ways you mention may be the simplest or quickest to get started? you think a raspberry will do the job (also considering the endorphin.es interface)?

thanks!

edit: i’m open to any other approaches you may suggest. this is really new territory for me

#4

If you want to integrate with eurorack, I recommend the OWL modular:

Two more options:

Bela.io eurorack version is under development, not yet available:
https://mobile.twitter.com/BelaPlatform/status/854978207954735104

Q-bit nebulae is discontinued, but perhaps you can find one:

If you decide to use a raspberry pi or Bela/beaglebone or an arduino (if you want arduino code, not Pd) you will need to think about voltage scaling. Eurorack can do 10V+/10V- and most cheap microprocessors prefer 0/5V+ (or less). You can build a summing amplifier circuit to convert and scale bipolar voltages to unipolar voltages.

Nice thing about the modules mentioned above is that they take care of this for you.

1 Like
#5

thanks for your help, jason! i’m slowly getting an overview :slight_smile:

1 Like
#6

I think it’s a good idea to stay in the midi domain as you described. you don’t have to worry about voltages and are flexible to connect to any midi hardware (or software). since you’re already into max, I recommend digging into pd on the desktop and then if you got something cool, running it on a rPi headlessly (no screen). this is because the video output is awful and by not booting into the graphical user interface you have a lot more system resources and much less system distractions, and it’s really the same pd as on the desktop. it involves getting comfortable with the command line a bit, but there are so many resources for that, it’s not too hard to learn (making notes helps a lot when coming back at a later point).
I don’t have a recommendation for a distro as I haven’t toched a pi for a long time, but generally raspbian/debian are more ready made installations but potentially more bloated with software you won’t need (while arch linux is a lot hackier), but if running headlessly this shouldn’t affect you too much as you’re not starting up the whole system. besides, a midi application isn’t performance heavy at all as audio or video would be. there are numerous tutorials online on the matter with possibly slightly different solutions, be sure to match OS flavour (arch solutions won’t work for debian). folks have already run serialosc on a rPi, there should be some info around (or at least the knowledge in the community).
and if you haven’t checked yet: http://monome.org/docs/grid-studies/pd/
a usb hub should be no problem, but it likely needs to be powered separately.
good luck!

1 Like
#7

thanks so much, @sakul – perfect summary of what i was hoping to grasp :slight_smile:
now a really banal question: i’d consider ordering a rPi right away, just to fiddle around a bit… there are so many different versions; supposing i’d get some Pi 3 – is there anything else i need to watch out for?

last: do you know from the top of your head if i need to get a screen / keyboard etc with it? or is there some (simple) way to remote control it from my mac?

thanks again, very appreciated!

#8

oh, and one more thing: being a total novice as for PD – do you know if i can use externals and things like this? meaning … will anything i patch in PD on my mac also run on the rPi in theory?

#9

The RPi3 has integrated wifi, so you can just connect it to your local network and login via ssh from your mac. If you need GUI apps you can use ssh -X, and if you want a full desktop you can run a vncserver on the RPi and access it from any other computer.

not necessarily. I’m not a PD expert, but in the past for externals you had to make sure that they were compiled for your system (linux arm, osx,…). It appears that Deken (the external manager embedded in PD vanilla) resolves this problem and builds externals on your target system so that should not be a problem.

#10

additionally:

I’d get a rPi3 yes, not the zero which is trimmed.

yes, the procedure for remote is to ssh into it while connected over network (ethernet or WIFI). I remember a lot times when I was happy to have keyboard and screen around or it was even indispensable, but only during custom installation, because this needs to be set up first to work. But there are ready made system images with default installations around, where you have all the infos in the docs how to install and remote access it. Or installers, where you can configure the OS with a text file first.

I must say I’m not familiar with the new Deken packet manager, but PD extended certainly was available on the pi. So as long as you don’t run that esoteric third party external, you should be fine I guess.

1 Like
#11

Ignore me ignore me.

2 Likes
#12

I did get my greyscale monome running quite well through PD on the RPI3 a while ago, but it was a bit of a hassle to set up. PD on the Raspberry Pi is a dream, just “sudo apt-get install puredata” for a vanilla install, but the monome serial connection was a bit more challenging, I had to mix and match a few tutorials to get it happening. If you are interested, I have got some notes lying around somewhere.

Also, if you are pretty good at max, then you will have a pretty massive headstart in pd; they are very similar aside from some small ordering (and a lot of superficial) differences.

edit: it may also be relevant to point out the pisound comes with midi plugs, although I’ve not had a chance to test it yet.

#13

thanks @pxxlhxslxn! great to hear that you’ve been down a similar road. i’d be really happy to get a hold of your notes, as i have no clue of the pi (and will most probably stumble upon many more difficulties than the serialosc connection).

if it’s no effort for you, please do post or PM me your findings.

#14

no worries, on the weekend I will track them down and post up a step by step to what I did. This has got me thinking though, I wonder if there would be interest in a disk image based on jessie lite, which has all of these steps implemented already so that those who are interested can just write the sd, plug and play? The monome/pi combination is pretty nice - think of the portability!

2 Likes
#15

Check out this thread:

And the spreadsheet we built from that thread:

2 Likes
#16

to finalize this thread i started and the lessons learned, i’m dropping this here. thanks for all the help!

2 Likes
#17

dear all,

after fiddling with this setup for the better part of the past 6 months, i’m really happy about how it works! yet, there’s one thing that i can’t get fixed. i’m aware that this is a very vague explanation, but maybe someone can point me in any direction to pin the problem down or has similar experience.

every first time i auto-boot into my (non-gui) Pd patch (it’s a step-sequencer), the grid loads up and the sequencer seems to be working, until after ~20 seconds, it appears to “clog” up. i’ve written a log file via Pd but the only thing i can make from it is that Pd starts its watchdog-process. in rare cases, it works again after a few seconds – but most of the time i need to cold-restart the rPi. in this case, it always works flawlessly without an exception.

i’m trying to pin down why on nearly every first boot, i’m getting this crash – or better, why on every second boot, it doesn’t occur. i’m still very new to debian (running STRETCH), so i haven’t even figured out where to look. this behaviour is somewhat confusing, cause it’s so non-erratic. i can’t wrap my mind around what could happen after a second system-startup.

any tips or things i could try out are very appreciated!

#18

(i’ll give this one small bump – sorry for being pushy! :persevere:)

1 Like
#19

Sorry for my “newbie” answer, but in -verbose without auto start of the patch, does it say something when you run the patch ? I ran into the same kind of issues with a low buffer causing Kernell Panic… and the patch was loaded “too fast” before the sound card and that was also causing issues, that’s why I’m asking :wink: that was with Purr Data, not happening now with PD Vanilla + tweaking the timing in the startup script

1 Like
#20

thanks for helping out, @Nordseele
the verbose output doesn’t log anything unusual… but – the issue of booting too fast may very well be the problem.

i’m really new to ubuntu – my bootscript looks like this:

sleep 4
serialoscd & 
sleep 8
pd -nogui -noaudio -mididev "1,2" -verbose -stderr /home/pi/Desktop/share/Seq/mainboot.pd > /home/pi/Desktop/share/mylog.log 2>&1 &

could it be that i’m missing some “&” or “;” somewhere – or that the sleep command isn’t the thing to use?

#21

To be honest, I followed your own instructions in this forum to create my first Raspberry Pi “DAW” … thanks for this tutorial by the way :wink: the sleep command was not the issue but I remember I had to tweak the Pd command and include the name of the audio interface directly in the command line, be as precise as possible regarding the buffer, the audio I/O etc… (start serialoscd, start Pd, wait for PD to start, give it a few seconds and start DSP, then make the ALSA connection for midi and audio) I understand you are using a custom “hat” for your sequencer, that’s why I can’t give a precise answer. I’m using an ES-8 on one Pi and another Pi lives in a Terminal Tedium. I’m sorry I can’t give a direct solution to your issue but yes, it might be a timing issue, or buffer, a very low buffer was causing freezing. What happens if you boot the Pi without Pd, wait a few seconds and load the script “manually” ?