Thanks! Will look into it when time permits.
thanks guys!
so, can i use the organelle patches on the raspberry then?
^ You should be able to.
Just bought a 9 inch LCD and enlcosure kit for my pi in the studio https://shop.cyntech.co.uk/collections/hdmipi/products/hdmipi-9-lcd-screen-kit
Going to mount it on the wall and use SEQ24 with a 4 port USB midi interface to drive all my Roland Boutiques, Reface DX and some midi to analog trigger gadgets and midi to CV stuff, not sure how well it will work with my other gear but I don’t envisage any problems.
Also probably will use it for some PD and SonicPi for sampling fodder, as well as using audacity for some simple audio editing duties.
1 Like
2 Likes
wondering if any of you regular Pi folks know whether one can run PD or less basic alsa commands at teh terminal level as scripts etc - i.e. can PD be run at some level without starting a PI GUI environment
i’d recently revived an old script i made way back when the very first Pi came out - basically as a USB Midi host - i’ve had to restructure this bash script a bit to account for the fact that the Korg SQ64 shows up with Multiple entries and it’s not the first entry which you need - the syntax of scripting (on a normally headless device) meant that debugging was tedious, shuffling between two rooms etc
That’s all good - but in addition to ‘smart’ pairing of any available controllers/modules - i’d like to introduce the possibility to cycle through ‘hidden’ multitimbral programs in my son’s Roland Piano (no screen and there’s a whole bunch of impressive stuff otherwise far out of reach) - this means a way to use GPIO to run a terminal script that can script MIDI
Not sure that PD could be run that way, but perhaps ALSA can be deployed which might be a bit more tedious - anyway, anecdotal feedback about there being zero hit for loading the GUI would be interesting to hear about - keep in mind this is the very first Pi
thought or links welcome to this general area - might have to look into what void did above to glean some inspiration.
Korg SQ64 has a lot of legs, but is not such a great combo with this Roland’s default GM piano - i need a way to send program changes - the bluetooth hook-ups are a bit flaky from smart devices (it only has a USB Midi port, doesn’t even have audio outs - only headphone outs!! great Piano modelling and keybed though when used for its day job)
Looking to add some fun to it with the SQ/Pi/powerbrick and a means to physically run scripts (even monitoring MIDI activity would be fine) - just want to avoid adding latency
1 Like
I’m definitely not an expert but I once run PD on a Raspberry without the GUI. The command was as simple as typing « -nogui » or something like that.
I found the info quite easily on the web, but I can check when I’m home in a couple of days.
1 Like
ahah cool - i was really so convinced that would be off-limits i didn’t even search - interesting !
hopefully there will be a way to do lots of this with PD as i’m fine in Max/MSP
will aim to establish if headless PD stuff can run and monitor Midi USB note/control input whilst a shell script links the hardware … ideally with no impact on the ‘host’ connection
okay this sounds like it has legs 
Further thoughts on this headless Pi situation
I’ve got a launch Pi which i’ve set aside for USB Host and controller duties
Currently the main thrust of this is to make access to the innards of a Roland Piano possible … there’s no screen and it uses key combos to load sounds, but there are multitimbral sound engines hidden from view and exploiting that will add another dimension to my Son’s learning on that (and me too)
I’ve done a quick check on pattern matching to change sounds - playing specific keys in a defined order - a bit clunky, but a first proof of concept.
This Pi will not start X windows (not even loaded into OS) - so i wrote off the thought of an interface, besides maybe a few pots and switches to scroll through settings - but the relatively cheap price of oled screen (using 12c protocol) caught my attention and it became apparent that this would be perfect for this setup - i can do all the midi stuff in Pure Data and ideally establish a way to get those numbers out and rendered on the screen - even allowing for dialling in and selecting effects - it’ll add a lot to the table
Then the thought struck me, with all these original iphones lying around - surely there may be a way to present data over the network such that the phone can present an interface of sorts (not a remote desktop view or a SSH terminal view) but a way to tackle this issue in preference to possibly using the OLED
Googling this brings up results which are 100% about using the phone as a remote screen - rather than as an addressable terminal or something more first principles - don’t think i know the right terms to google that may narrow down my searches
but i’d be interested in any insights or user experience with the oleds and scripting text to those from a command line os or using old phones as interfaces or other ways to achieve teh same end - the og pi has two usb ports, so i need both for the piano and controller - so USB solutions may not be ideal, it has ethernet and i can SSH into it from other devices so maybe a networked solution or an oled/switch/pot gpio solution is what i’ll end up with and that seems well discussed (although maybe not in terms of Pure Data ‘integration’)
thoughts/terms welcome … to steer me in a productive searching direction
short answer : using oleds is easy and cheap 
longer answer:
interfacing with phones…
so the problem is, you have to have a protocol and then something to talk to on the other side.
remote desktops seem a bit heavy for this.
I guess if its an android phone, you could write your own app ,and your own protocol… but thats getting to be quite a lot of effort.
if your familiar with web technologies, then you could use this … so you use your phones browser, and basically run a server on your rPI talking to your app.
(this is become a common approach for embedded devices)
of course, other question here though… at this point why use a rPI at all… just run the app on your phone
OLED/pots/encoders
main advantage is it standalone.
writing to oleds is pretty simply esp. since a lot of them use the same I2C or SPI protocols,
so there are a ton of C++ libraries, or even python to help with interfacing to them
similarly there are a ton of open source projects you can go check out the code for.
e.g. the Organelle M by Critter and Guitar ‘mother’ code is interfacing with oled and encoders, so would be a good starting point.
as for interfacing with PD, two choices really :
easy : have the hardware code running in a separate process, that communicates via something like OSC to PD (approach taken by C&G for Organelle)
bit more involved: write a PD external which talks directly to the hardware
its a bit more involved, since it’s likely to have to beC/ C++ ,and you need to do hardware interaction in separate threads.
Ive got some code that did this for Terminal Tedium.
so if you want a simple solution, and perhaps to prototype…
Id be tempted to get an oled and encoders, and perhaps look at doing it in Python.
(just make sure the oled you choose is supported by the relevant python library)
1 Like
I am not 100% sure but WRT the iphone there are a couple of apps that might do some of what you want PDparty or MobMuPlat but check as it is a long while since I tried either of them.
1 Like
The pi is primarily my USB host for the devices which don’t have any regular midi
But thanks for the comprehensive points, lots to feed into this and it’s good to hear that the oled approach is sensible as it’s probably the most fun to attempt tbh
The web angle is something I had overlooked completely. Food for thought
Good shout - I did use an app on the og iPhone that required addressing the phone with openGL through an external in a Max environment. It shows, along with those linked apps( one of which I definitely have), that something could be in reach that way.
Ideally doing something with an oled and buttons etc will fire up my son’s imagination for making, so I may gravitate to that first.
yeah, messing with hardware with the rPI is a lot of fun - its also very accessible, since the rPI was developed as an education/diy platform , so there’s a ton of resources out there on how to do this kind of stuff.
once you get over the initial hurdle, its probably simpler than trying to interface with other software - which frankly, is often not much fun at all 
1 Like
If you are only handling MIDI on the Pi, I might suggest having a look into Python (and rtmidi library).
PD is cool, but I found it a bit clunky and overkill for MIDI processing.
I have a Pi (v2) running as a MIDI backend.
Remotely controlled via OSC (Processing sketch running on an old tablet)
Also, yes there are a few ALSA commands are available via the CLI.
1 Like
Indeed there is, but that brings issues with being up to date and so on… too much information for the adventurous novice to trip up on !! … the info is there but for googling you need to be aware that there will probably be issues - I had no end of difficulties getting Pure Data on tbh and then found out about incompatibilities with this and that, so I’m starting afresh with Buster on both(also have a pi400 for son) and trying to use them more actively so they are current. It’s fun, but a certain level of skill is helpful, I can just about wing it to certain outcomes but it’s a slog at times. Programming bash scripts to do alsa midi connections necessitates learning all the nuances of Bash through trial and error after error. But it’s still rewarding and fun and whilst the pi will still be a nice cheap hub, it’s obviously one of few options that readily facilitates all the customisation needs I have in my case. That side of it will be rewarding and give extra life to two devices.
I’m surprised at how much i liked PD though as a seasoned Max/MSP user.
Tbh I’m still not running version 5 as I failed when compiling that, albeit the reasons escape me, but it seemed like it was time to update everything. The og pi was running wheezy and some links had vanished iirc.
Yeah - another avenue there, I saw python pop up a lot in the learning resources for my son’s microbit and the pi stuff so that makes a lot of sense but I’d be signing up for another steep learning curve in the short term, whereas I can knock up a pd sketch in no time
I won’t stop at one solution if others are available. But getting quick access to the Roland’s hidden engines one way or another will open up a lot of functionality in the short term.
1 Like
Yeah I know…
Start today.
Python is surprisingly easy though (and did I mention fun?), compared to other languages I have dipped my toes in.
And extremely helpful for all kinds of tasks.
ALSA tip:
aconnect -i
aconnect -o
list all MIDI ports (in/out respectively)
Usually you get one “client” for each MIDI device, which can have several ports attached.
i.e. you might see output like this
client 24: ‘Launch Control XL’ [type=Kernel,card=2]
0 ‘Launch Control XL MIDI 1’
1 ‘Launch Control XL MIDI 2’
client 28: ‘Some other Device’ […]
0 ‘MIDI 1’
To connect these for example, use:
aconnect 24:0 28:0
To disconnect:
aconnect -d 24:0 28:0
For more:
man aconnect
1 Like
Good to know along with that OSC tip, which I think was integral to the stuff I did on the original iPhone to control a Max synth. I just needed a few of these buzzwords to hone my searches better.
It’s been sitting for a while unfinished. Except q working solution via Max, but this means hooking up a Mac mini and it becomes less child ‘safe’ and no longer an autonomous endeavour. Thus a cheap ageing pi seems a great candidate and a nice learning platform to boot (no pun intended)
I recall having no joy trying to find a way through this using web MIDI, I couldn’t get that off the ground afaicr. There was a dearth of info on that, or stuff that was beyond my skillset.
I’m only aware of the existence of python so it’ll be fun to see what scope it could have especially if it’s user friendly for dabblers. The issue I have with these tools is that they’re not like riding a bike. I forget very quickly what I cobbled together in a concentrated push, even with annotated code. When I started off it was Fortran 77 ! I hadn’t touched a computer until uni although I knew of kids with BBC micros
1 Like
Thanks for those additions in your edit. The alsa hookups were one thing I managed back in the day. I’ve even scripted the bash stuff to detect device names and pick the two connected automatically (because headless) - all very clumsy but it works and i’ve tidied up the bash a bit recently which was painful to get right as you forget all the nuances - even when you have a working script that you wrote yourself to refer to
i think I’ve now got the alsa stuff working via pd, maybe via a shell external which is handy - all a bit clunky but robust - always keen to learn - but not so good at getting up to speed because of this flagging ability to use the best search terms i guess - as a non programmer
all good fun - when it eventually works !!
1 Like
Im not a big python fan…
but it is a great tool , very easy to learn and has a ton libraries, and again loads of educational material.
for things like midi, I find text based/procedural languages are easier than things like PD… as it’s all logic like ‘if this do that’ which is not PD strength imho.
so id expect a small learning curve, but after that, I think you’ll find progress is much quicker.
(for me PD strength is more prototyping in the audio realm… so creating synths and fx)
OSC interfacing is a good idea…
I know quite a few musicians who love using things like touchOSC and Lemur for building interfaces into things like rPI and instruments.
2 Likes