Home News Store Community Docs
   Menu

Amidiminder utility

Patchbox OS
#1

Alas, sometimes USB cords get pulled accidentally, or devices get switched off and on. In the middle of a set, I don’t want to have to aconnect the MIDI ports again!

amidiauto takes care of this for may set ups, but not mine: I have a more complex set up, with specific devices connected to specific places.

Enter amidiminder: This little app simply keeps track of all the ALSA MIDI connections made (whether via aconnect or via other software, like SuperCollider) - and remembers them by name. If a MIDI device goes away and then later comes back, amidiminder will connect it back up as it was before. It works even if devices are reconnected in a different order.

This project is working and available on github: https://github.com/mzero/amidiminder
It’s pretty early going, and you’ll have to build it yourself. Open to issues, bug reports, pull requests, and discussion.

Perhaps there is some natural merging of the functionality of this and amidiauto… seems likely to me, but it wasn’t immediately obvious how to meld it, and the undocumented file feature in amidiauto…

2 Likes
#2

I’ve been thinking more about how to merge amidiminder with amidiauto. The things amidiauto was missing for me:

  1. Handle clients & devices with more than one port in each direction. For example, Launchpad Pro has three bidirectional ports. SuperCollider can have many more.

  2. Observe software that makes connections, and maintain them. aconnect, Patchage, and SuperCollider can all make connections - but don’t “reconnect” if the devices disconnect and reconnect.

On the other hand, amidiauto offers a way to declare specific connections you want, and ensure those get made. And it can do this by “class” of port and device.

I can see how to extend amidiauto's file format to support port numbers and names. I can also see how to incorporate both connections made via the rules, and connections observed from other software. However… I feel like I’m not clear on how amidiauto is currently used:

By default it will just connect all hardware ports to all software ports. This works for simple cases: “just connect my midi note controller to the current running software thing” - but fails for larger setups where you might a devices with multiple ports, controllers that are knob/fader boxes going to one software or one port on a program, and note contollers going to different ports. Nor does it handle external synths well when there are more than one if you need more control over them than just MIDI channels

To handle these more complex cases, amidiauto has a file rule format… but it isn’t documented in the man page. What isn’t clear to me is how do people use that file? Is having just one file in /etc enough? Do you need one per “scenario” and away to change between them? Does anyone use the [deny] feature, and if so how? There are some internal subtle logic around rule “priority” that is hidden from the file… does that work well?

If anyone uses amidiauto's file feature - I’d like understand how you use it - and what your set up is like.

1 Like
Midi connection manager
#3

Looks like a very useful utility. These are very good ideas. :slight_smile:

Indeed, it’d probably make sense to merge the functionalities into one process. Maybe amidiauto may be monitoring the connect/disconnect events and update its rules file, whenever the user or some other software make changes to the virtual MIDI connections in any of the other software. This would also spare amidiauto from eventually needing a GUI. :slight_smile:

Regarding /etc/amidiauto.conf - we allow Patchbox Modules to have their own amidiauto.conf versions. So it allows having different setups for different modules. But still, everyone’s setup is different, so editing it for custom setups would be necessary.

For the rules of the config file - there’s 3 levels of possible rule strengths - very specific, vague (when one side is named, the other is a wildcard ‘*’), and weakest - wildcard on both sides. amidiauto puts ports into ‘software’ and ‘hardware’ categories. When considering a port, a wildcard always matches the ports of the opposite type, in order to do the software and hardware port connections. When evaluating whether particular ports must be connected together, the strongest and most explicit rule wins. Also, it’s possible to have wildcard allow rules, but explicitly deny connections in the [deny] section. The default rule for amidiauto is * <-> *.