Midi connection manager

#1

ok, before I go and write this … can someone tell me if the following exists :slight_smile:

what I want is for the rPI running headless to reconnect all midi devices in a provided configuration.

now the rules of the game are simple:

  • im talking ALSA
  • it has to support usb devices
  • it has to support virtual midi devices (like PD)

ok, so its the last two that cause the ‘issue’

we can obviously do:

aconnect "Virus TI:1" "Pure Data:0"
aconnect "Pure Data:1" "Virus TI:1"

but the issue is, when you run this you are assuming 2 things

  • Pure data is running (otherwise the PD ports are not there, so it will fail)
  • the USB device (virus in this case) has to be connected

if either is not the case aconnect will fail,
it will also fail if you restart PD, or restart the usb device.

yes, I could do a sytemctl script, that waits for PD, and make sure the device is already on, but thats not nice, I want it to be a bit more thorough than that…

and I also want if it fails, for it to ‘fix’ itself without the user getting involved by manually running something, hitting a button etc.

so what I want is something that takes these mappings and monitors for devices/ports to become available and then it makes them.
preferably the mapping is in a config file (rather than a script) so its easier for a user to edit.

surely this exists already?

0 Likes

[Beta] Patchbox OS image 2019-02-27 (Updated 2019-03-13)
#2

For the upcoming App update, we had a need to have a ‘osc to (and back) MIDI bridge’. I could only find existing solutions with lots of external dependencies, so I decided to build a very lightweight daemon process with dependencies only on libasound and C / C++ standard libs, was going to publish it together with the App update release, but here it is: https://github.com/BlokasLabs/osc2midi

At the moment it’s not making any ALSA MIDI connections there, but I’m considering extending it (or building a separate dedicated daemon) to automatically make subscriptions for every port as they appear, there are events generated by the ALSA lib when new ports appear and old ones disappear.

The reason I’m showing the osc2midi now is to demonstrate that not a lot of code is needed to work with MIDI events on Linux, the ‘port appeared / disappeared’ events could be captured to implement automatic connection making, in case of osc2midi to its own virtual ports, or in case of a generic MIDI connection manager, make the connections based on provided rules.

In our experience, the rule ‘aconnect everything to PD and PD to everything’ goes a long way, so that’s what we’d start from. :slight_smile:

It is surprising why there’s no existing solution like that out there, or at very least it’s well hidden if it exists.

1 Like

#3

thanks, I messed about with the asound lib a quite while back, to help integrate alsa into bela - so could dive into it again, was just hoping this was a ‘solved’ problem :slight_smile:

not sure about connecting to every port,
one thing I recently did on organelle was to allow you to connect different midi devices to different pd virtual devices, this is particular useful for MPE where one device uses all 16 channels :wink:

but keeping it simple, at least to start with, is a good idea.

hmm, will have to think about it… need to pick my battles at the moment.

0 Likes

#4

My situation is a little different, but this might help: Live I have a big Pd patch that is both audio effects controlled by MIDI controllers, and a MIDI router between keyboard (-ish) controllers and synths. Depending on my mood and what I pack to a gig, which controllers and synths I have varies… but I want to run the Pi headless… so I needed a way to have the whole thing automatically patch as needed…

I use this script:

#!/bin/sh

aconnect -x

try_aconnect() {
	aconnect "$1" "$2" 2>/dev/null && echo connected $1 '-->' $2 || true
}

# in Pd, four midi devices appear as 0~3 in, and 4~7 out
try_aconnect 'Faderfox UC44':0 'Pure Data':0
try_aconnect 'Elektron Digitakt':0 'Pure Data':1
try_aconnect 'Circuit':0 'Pure Data':2
try_aconnect 'PreenFM mk2':0 'Pure Data':2
try_aconnect 'pisound':0 'Pure Data':2
try_aconnect 'nanoKEY2':0 'Pure Data':3
try_aconnect 'DU-TOUCH S':0 'Pure Data':3
try_aconnect 'Launchpad Pro':1 'Pure Data':3

try_aconnect 'Pure Data':4 'Faderfox UC44':0
try_aconnect 'Pure Data':5 'Elektron Digitakt':0
try_aconnect 'Pure Data':6 'Circuit':0
try_aconnect 'Pure Data':6 'PreenFM mk2':0
try_aconnect 'Pure Data':6 'pisound':0

Essentially, I define four ports, for four different functions in my Pd patch:

  • port 0: main knob/fader controller
  • port 1: drum machine
  • port 2: synth
  • port 3: note controller

Then this script just attempts to hook up everything… and is tolerant of missing devices.

I’ve arranged for this script to run after both as the CLICK_3 script, and at the end of the CLICK_1 script.
I can thus re-connect devices on the fly.

1 Like

Best way to auto-start/integrate PD?
#5

Hey! We have built a minimal background service for making MIDI connections automatically, called amidiauto

It’s integrated by default in Patchbox OS image, but it can be installed manually by doing

sudo apt-get update && sudo apt-get install amidiauto

It categorizes all of the MIDI ports available on the system into ‘software’ (such as Pure Data, Super Collider, etc…) and ‘hardware’ ones (such as MIDI DIN5, external USB controllers, touchosc2midi, pisound-ctl, etc…), and automatically makes the connections between the hardware and software ports as soon as a new port appears. If a device or software has more than single MIDI input and output, only the first pair gets used.

I think this covers most of the user use cases, but of course some special case configuration may be necessary to suit particular setup. At the moment this facility is not implemented, but we’d be very interested in feedback or even pull requests for the tool. :slight_smile:

2 Likes