So as I’m bedridden with the cold from hell, I figure I’ll spend some time plinking at setting up a Touch OSC bridge on a Raspberry Pi 4. After getting Pure Data working with remote X11 display, I thought it might be nice to have some way to control parameters other than poking at very tiny text and widgets on my old Wasabi Mango 40″ UHD monitor.
The Iron Chef ingredients for this project are:
- A mobile device running TouchOSC
- A Linux TouchOSC bridge and a host to run it on
- Some app or process that listens to MIDI and does something with it.
The goal of the project is to control one or more parameters in a Pure Data patch via TouchOSC through MIDI. The Minimum Viable Product is the printing of MIDI information to the bash shell’s standard output. Yeah, Pure Data already supports TouchOSC, but if I’m going to do the work, I want to be able to control something besides Pure Data eventually.
So let’s break this down. First, TouchOSC.
TouchOSC is a touchscreen-focused bag of widgetry implementing Open Sound Control which is essentially a messaging protocol designed for real time control of media hardware.
TL;DR: MIDI sliders on your phone or tablet.
Obviously, to get what you see in the pic, I need to edit the UI, which is a pretty simple menu-driven process of creating widgets, assigning control definitions, and setting value ranges.
This is running on the Pi itself and displaying in an X11 window on my Mac, because why not? That’s a nice segue into getting the editor running on Linux.
The TouchOSC website has download links for the linux version of the editor, which is just a java .jar file. I’m expected to have the java runtime environment installed on Linux, and for this, the default-jre package works. I’m not sure if binfmt-support is required, but it was already on my system, so I guess I wouldn’t know. So to get what I got in the pic above, I need an X11 server on my Mac (XQuartz), and I need X11 forwarding on the Pi, where I log into the Pi from bash using the ssh -Y command.
Now, on to the bridge.
Spoiler: There’s no official Linux Touch OSC bridge. As I said before, Touch OSC is an implementation of a protocol, aimed at enabling creatives to combine and control pieces of gear that may not have been designed for it, without the need for a CS degree. It’s a safe guess that 90%+ of the user base is working with Mac or Windows as a creative computing platform, so it’s plain to see why the dev resources of Touch OSC are spent there. Fortunately, the Linux development community is large enough so that awesome developers fill pretty much every niche of the ecosystem, including Open Sound Control and Touch OSC.
After a bunch of googling, it looks like there are numerous github repositories full of implementations of OSC for various things in various languages, but most of the ones I found implement it either in Node.js or Python. I was never a web geek, so I never learned to write javascript, but I know Python from visual effects and game development, so that’s my go-to hacking language for anything other than Unity 3D, which requires .NET/C#. There’s TouchOSC for Unity and Unreal as well, but that’s a massive digression.
I picked this github repo as my starting point. Since I’ve been around the block with Python before, I decided to try to make it work in Python 3. Raspbian buster installs with both Python 2.7 and Python 3, but the default Python is set to 2.7, presumably for backwards compatibility with older scripts. I’m going to try to live my life without Python 2.7 from now on, so I changed my default Python to Python 3, which is explained here.
NOTE: As usual coloring outside the lines gets me a beatdown. It’s far easier to set this up using the docker container in the repo, but I want this on my actual system. I also want to use Python3. I was able to install the dependencies OK:
487 sudo pip install zeroconf
489 sudo pip install python-rtmidi
491 sudo pip install python-rtmidi
492 sudo pip install liblo-dev
493 sudo pip install librtmidi-dev
496 sudo pip install librtmidi-dev
498 sudo pip install liblo
but the repo’s pip install requirements specify Cython 0.25.2, so changing that enabled pip install –no-cache . to work. The –nocache flag is important because after a ton of failed installs, the cache file is likely a steaming mess. If all this goes well, touchosc2midi should be working on the command line.
Some of these steps and processes might seem really opaque and confusing, but that’s how it is with this stuff. The best skill I’ve developed is how to connect the inputs and outputs of the various guides and documentation to each other. At some point, this eventually morphed into the skill of actually passing data between software libraries, which is what lots of people call “programming.” It’s not exactly that simple, but that’s the idea.