right now it does only three simple virtual cables
I really want to know an answer to that naive noob question…
Midihub runs a dedicated OS for this, while Raspberry Pi Zero runs a full generic OS which takes some time to boot before it’s ready to route USB MIDI.
While what @Giedrius said is true - a Pi can still boot relatively quickly.
I measured how fast my system starts passing MIDI:
- connect a controller sending 16th notes over USB MIDI to the Pi
- connect a synth via USB MIDI to the Pi
- add a rule to
/etc/amidiminder.rulesto connect them - shut down the Pi, unplug it
- plug in the Pi & start stopwatch
- wait for first note on the synth, and stop the stopwatch
My system does this in just 10 seconds. Probably not as fast as MIDIHUB starts - but fast enough for using in live performance situations.
If yours takes appreciably longer, perhaps start a different thread and we’ll help debug what it taking your system so long to boot.
Finally I had some time to test amidiminder. It works great with MidiHub and my multi-device setup.
Thank you for all the time and effort you put into it.
I struggled a little with two topics:
-
The inital standard rule (.hw <—> .app) was much too ‘aggressive’ for my setup. Suddenly everthing was connected to everything. A hint/warning in the ‘Install’ chapter of the very good readme would be nice.
-
A ‘rules generator’ would be nice for larger setups.
amidiminder -p | grep ‘connection’
does half of the trick and lists all active connections in almost the right syntax. However (being a linux noob) I was not able to pipe it into a file. So some cut, paste&edit was left to do. Maybe a modified -p routine can generate a .rules file out of the currently active connections.
Thanks again for the great tool.
Regards,
RoDi
1 Like
Just wanted to explain the rationale of this default rule - it’s to cover the simple case of users running some audio synth software, and have a single external keyboard hooked up to the system and expect it to just work. It should be a common enough case to have it as the default one. I think it’d make sense to note it somewhere as suggested for users with more complex systems.
Btw, @mzero, the amidiminder would connect every port of a software multi-port client to every port of a hardware client? This might be a bit excessive in multi-port client cases. Do you think it’d make sense to limit this automatic rule to only make the connections between the first ports of multi-port clients?
@RoDi - I’ll think about adding some flags to amidiminder to list existing connections in rule format.
The default rule is to mimic amidiauto's behavior. It should be more called out in the docs.
@Giedrius - The default rule operates similar to how it does in amidiauto: only one port will be connected between a hardware device and an application, even if either offers multiple ports.
[Geeky details: The mechanism is a bit different in amidiminder: A connection “proposed” by a rule is ignored if the pair of clients already has a connection that matches that rule. In most cases, it amounts to the same outcome as amidiauto's technique (only connects the first port of any client) - but there are corner cases that differ.]
I’m also finding myself wanting to use amidiminder's syntax for making connections on the command line. I’m planning on implementing all the functionality of aconnect - only you’ll be able to use the easier name and matching abilities… and the output for -l will be more legible… And then you can simply simlink amidiminder to be aconnect.
3 Likes
i just did the install. It worked straight away. I am using it with MIDIHub and an RD-88. The RD has a MIDI out but no MIDI in and so the USB has to be used. A few notes. Running ‘amidiminder > ports.txt’ creates a quick file to inspect the names of the attached midi devices. It would be nice to have a switch like ‘-i’ so that I don’t need to cmd-C to get out of it. I used this file to develop the rules.
Regarding wildcard, i think it is fine as long as one knows ahead of time what that means.
Does amidiminder log if there are connections and disconnections?
Thanks for this! I thought I would have to write my own!
.m
You should be able to see that using:
sudo journalctl -u amidiminder -f
I am not much of a rasbpian, so this command helps.
.m
Blokas Team, Can this be added to the Patchbox OS build ?
1 Like
Yes, we plan to replace amidiauto with amidiminder in the next update. 
4 Likes
Yikes! I better get cracking on cleaning it up!
2 Likes
I wrote an amidiminder rules file but I encountered the same issue as this person here:
Can you show us the contents of your rules file, the location of it, and the command you’ve used to run amidiminder?
Checked and made some edits to the rules file in the etc folder. I misunderstood the syntax for denoting which MIDI port to use on each device.
Then I ran amidiminder -C to check the rules file but once again got “no rules file specified.”
I thought I’d give it a shot anyways so I did sudo systemctl restart amidiminder & I got no error messages. Then I ran aconnect to look at my connections and everything was the way I wanted it.
Forgive me if this is a foolish question, as I’m not really much of a coder, but would amidiauto or amidiminder be the commands I would need to run after connecting my USB midi device to get them to be recognized by my Pi running MODEP? Currently they don’t show up at all when I run amidi -l
Thanks so much 
No. When USB midi devices are connected, the ALSA subsystem in the kernel automatically detects them and adds them. There isn’t really a command to run to get them to be recognized.
The command amidi is for dealing with “raw MIDI” ports. In ALSA there are two kinds of MIDI: “raw MIDI”, and the horribly named “Sequencer”. In practice, most things deal with the later kind of MIDI, and there are different commands for it. Use aconnect -l to see if your device is there, and aseqdump to see any MIDI it is sending to your system.
Either amidiauto or amidiminder is used to connect various “sequencer” MIDI ports together. MODEP creates an “application” port - and when a “hardware” port appears in the system, either of those commands can be configured to automatically hook up “hardware” and “application” ports to each other, connecting the device into MODEP.
2 Likes
You need to tell the command which rules file to check:
amidiminder -C -f /etc/amidiminder.rules
# or
amidiminder -C -f myalternaterules
3 Likes
Thanks. This is helpful info, I’ll try it out.
Hey @mzero,
many thanks for creating amidiminder! I’m running it on a RPi Zero with RPiOS lite, installation was easy and rules work like indented.
I’m having one issue, though. My use case is to run amidiminder as a USB MIDI host to send signals from several USB-controllers to a KeyStep and from there via MIDI out to several hardware synthesizers. The controllers are all connected to a powered USB-Hub. When the system is up and running I can plug in other controllers without any problems. But as soon as I remove one controller from the USB-Hub, the RPi becomes unresponsive and/or crashes.
I’ve seen this happening with other tools I’ve tested, too, like rpi-midi-hub, so I guess it’s more a general issue. I think it happens, because the connection between the controller and the KeyStep stays open, although the actual device isn’t plugged in anymore. Do you have any further insights on this?
Best
Torben