I’ve been thinking more about how to merge amidiminder with amidiauto. The things amidiauto was missing for me:
-
Handle clients & devices with more than one port in each direction. For example, Launchpad Pro has three bidirectional ports. SuperCollider can have many more.
-
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.