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 
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.
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.
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
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
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 !!
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.