At work we use an AMS Neve Genesys Console which is pretty great in a lot of ways. All of the internal routing, panning and channel EQ is totally recallable. Internally, the board is controlled by a PC running a custom Windows 7 front-end/wrapper.

The Genesys can also behave as a HUI control surface for Pro Tools but rather than interfacing with a slew of MIDI cables a Cat5e or Cat6 network cable connects the DAW computer to the Genesys’ internal computer. This isn’t a bad system, but if the DAW computer has multiple ethernet adapters as ours does, the ipMIDI driver gets confused.

ipMIDI isn’t developed by AMS Neve, but rather by a small German company, Nerds.de. The macOS driver is free, fortunately. Windows users must pay a reasonable license fee. I’m not sure why the discrepancy. Presumably Windows development was trickier? Or considered by the developers a niche market?

We are running Pro Tools on a 2012 Mac Pro tower running 10.11.6. First, the most recent drivers (ver1.7) did not function properly on this machine, but downgrading to ver1.6 addressed this. It took a lot of trial and error (and support from Neve) to figure this out!

Anyway, we experienced some difficulty getting the DAW control part of the console to play nice with our machine. There are 3 network adapters internal, including the WiFi adapter we use in the studio to connect to the internet. The FAQ on the ipMIDI homepage offers this advice:

Network traffic is controlled by the so called “Network routing table”. ipMIDI uses the default route like every other application (e.g. Web Browser). To change this behavior, add a routing table entry for ipMIDI’s multicast adress 225.0.0.37. This is done in a command window:

Windows:

route ADD 225.0.0.0 MASK 255.255.255.0 <static_ip_of_wanted_(W)Lan_card>
OSX:

route -n add -net 225.0.0 -interface

I followed the instructions to add an entry to the network routing table to direct ipMIDI traffic out a specific interface. This works but what the FAQ doesn’t mention is that on OSX the routing table resets at every shut-down. Every time you power back up, the command must be re-entered.

My band-aid fix has been to to write a brief shell script, make it executable and add it to the Login Items list in the Users pane of the System Preferences. The script still runs in the terminal and requires a password because of sudo:

sudo route -n add -net 225.0.0 -interface en0

For some reason I had a hard time getting this script to execute properly with the Login Items list so I triggered it using another shell script which would just call upon the original:

nohup sudo /Library/StartupItems/AddRoutes/routeipMIDI.sh &

Deep in the UNIX/BSD sub-layer of macOS there’s a sudoers file which dictates which users can execute which commands, and whether or not they need a password to do so. If I make a NOPASSWD exception for this user and this specific script in the sudoers file I avoid having type my password a second time on login:

This is okay, but irritating because the user still needs to close a Terminal window at every login. For the users I share this workstation with, that is confusing.

The bodge I used to address this was found on this Stack Overflow page:
http://stackoverflow.com/a/22447960

So, stealing a trick from one of the commenters there, I append the following command to my shell script:

osascript -e "do shell script \"osascript -e \\\"tell application \\\\\\\"Terminal\\\\\\\" to quit\\\" &> /dev/null &\""; exit

The osascript command executes a bit of Applescript from in the terminal.

Now the script does its thing and then immediately ends the session, closes the window and quits ther Terminal application. This all happens fast enough that if the user isn’t paying close attention they won’t even see any of this happening.

For the time being, this works. I would love to hear about a more elegant solution. Like, how the hell do you make a permanent addition to the routing table in macOS? In the meantime, this does the trick.