Amidiminder utility

This should not happen. Because it happens with other software… and because the RPi Zero totally locks up, I suspect this is a hardware issue.

Two things I’d check:

  1. Are you using a proper OTG cable to connect the RPi to the hub?
  2. Try a different hub.
  3. Are the hub, and any of the MIDI devices that are not powered by that hub, all on the same AC circuit?
  4. Is it just one particular controller… or any of them? What happens if you pull the Keystep out and re-plug it?

This isn’t really possible. The way that the Linux kernel manage all resources, ALSA MIDI ports included, is that when resources go away, the kernel gracefully handles their removal, and connections and uses of them are closed automatically. In fact, amidiminder relies on this feature to know what is going on with the MIDI setup.

2 Likes

Hey, thanks for your swift reply @mzero!

I did some more testing and connected the KeyStep and another controller directly to the USB-Ports of a RPi 2. This time I connected the Controller with the KeyStep manually via aconnect. When I disconnected one of the cables, the Pi became unresponsive again.

This narrows it probably down to the cables and I think I can live with it for now - it’s an edge case anyways. So thanks again for your help.

You should keep dmesg -w running on the Pi via ssh or even better with a keyboard and monitor connected directly, to see whether it produces some warnings or errors just before the system hangs.

What is the power supply you are using? Disconnecting devices may cause some voltage transients that might end up getting the main CPU stuck, if they go out of its operating range.

Is there a way to chain a midi-filter (for note on/off and cc for example) in a amidiminder connection?
(purpose: only clock should be transmitted)

Can I script this right to the amidiminder rules?

no, amidiminder doesn’t have processing of MIDI data… in fact it never sees the data, it just connects ports and the OS does all the data movement.

if you have software the does that filtering, you can use amidiminder to hook it up when you launch it.

You could do the processing on Midihub and have amidiminder send the MIDI data to and from Midihub between other software and USB devices.

Thank you @mzero for creating amidiminder, I believe it will help me complete my buildproject!

Anyone know why amidiauto keeps getting activated every time I reboot my pi? I’ve disabled it with sudo systemctl disable amidiauto.service a few times already but it appears active after a reboot. Should I use systemctl mask to have it permanently disabled? I’m afraid it’s causing issues with my connections (amidiminder reports observing many existing connections and only creating a few new ones) and would like to ensure it’s not creating a mess. Perhaps @Giedrius has input?

Edit: I found out the ORAC module has amidiauto as a dependency which is probably causing my issue. I guess the easiest way to go around this would be to use the masking feature of systemctl? Not sure if adjusting the module json is sensible as it might get overwritten with updates?

Yes, if the systemctl service is masked, Patchbox module manager won’t attempt to start it and just skip it, even though it’s set as a dependency. :slight_smile:

I’ve installed this program on my Raspberry Pi now, running Patchbox OS. It seems to run fine. For example, I can do

sudo journalctl -u amidiminder -f

and check that both of my devices connected via USB shows up. In my case, I tried disconnecting and then reconnecting everything, which gave me:

Aug 13 00:44:40 patchbox amidiminder[438]: port removed Roland Digital Piano:Roland Digital Piano MIDI 1 [24:0]
Aug 13 00:44:53 patchbox amidiminder[438]: port added Roland Digital Piano:Roland Digital Piano MIDI 1 [24:0]
Aug 13 00:45:01 patchbox amidiminder[438]: port removed Midihub MH-31KK5QB:Midihub MH-31KK5QB MIDI 1 [28:0]
Aug 13 00:45:01 patchbox amidiminder[438]: port removed Midihub MH-31KK5QB:Midihub MH-31KK5QB MIDI 2 [28:1]
Aug 13 00:45:01 patchbox amidiminder[438]: port removed Midihub MH-31KK5QB:Midihub MH-31KK5QB MIDI 3 [28:2]
Aug 13 00:45:01 patchbox amidiminder[438]: port removed Midihub MH-31KK5QB:Midihub MH-31KK5QB MIDI 4 [28:3]
Aug 13 00:45:06 patchbox amidiminder[438]: port added Midihub MH-31KK5QB:Midihub MH-31KK5QB MIDI 1 [28:0]
Aug 13 00:45:06 patchbox amidiminder[438]: port added Midihub MH-31KK5QB:Midihub MH-31KK5QB MIDI 2 [28:1]
Aug 13 00:45:06 patchbox amidiminder[438]: port added Midihub MH-31KK5QB:Midihub MH-31KK5QB MIDI 3 [28:2]
Aug 13 00:45:06 patchbox amidiminder[438]: port added Midihub MH-31KK5QB:Midihub MH-31KK5QB MIDI 4 [28:3]

Now, I would like to send midi data from my Roland Digital Piano to my Blokas Midihub. Do I need to edit the rules somehow? When playing the keyboard, I see no lights flashing on the Blokas Midihub (and my patch that I’ve loaded into it doesn’t work).

Yes, you’ll have to make a MIDI connection using aconnect or any other means between the devices, and amidiminder will remember it and apply it automatically the next time the OS boots or the devices get connected.

Try running:

aconnect 24:0 28:0
aconnect 28:0 24:0

to connect the piano to Midihub’s A port, in both directions. I took the address from your above output, they’re in [] brackets.

1 Like

Is there any work on amidiminder or will it come to patchbox OS?

Right now i´ve got that “no rules file specified” problem. Anybody can help with this?

1 Like

“no rules specified” is because you’ve not given the rules file on the command line. Try:

$ amidiminder -C -f /etc/amidiminder.rules

or replace with what ever file you are checking.

The service script is set up to invoke amidiminder -f /etc/amidiminder.rules and the debian package installs default rules there.

1 Like

thx for your help, I guess I had a typo in my rules

I’m having trouble getting amidiminder to employ rules on a Raspian OS w/Raspberry Pi 3B+. I can set rules fine and verify them via: amidiminder -C -f amidiminder.rules, and devices connect correctly when using aconnect, but the former (amidiminder rules) doesn’t allow implicit or explicit rules to create connections- even after the service restart (or reboot), and the latter (aconnect) connects fine, but doesn’t persist- as it should with amidiminder. Now, I have no doubt in my mind that I’ve configured something incorrectly, but I don’t know if it would be better to troubleshoot or just try to reinstall (or how to do so properly) at this juncture.

Edit: I figured out the problem. I wasn’t editing the midi port IDs in the .rules file properly. D’oh!

I have specified rules inside /etc/amidiminder.rules and everything works as expected. However, when I run amidiminder -C, I get a message saying No rules file specified, so no rules added.

This is a bit confusing I think. My rules have been added, but is the program talking about having an extra file that can be specified? Shouldn’t it then read something like No extra rule file specified, so only rules in the default rules file added? Or am I missing something?

I got my rules work now. Now the midi devices are connected right away when Pi boots up. They are connected for about 10 seconds and then the Midi get unconnected. Any ideas how to solve?

I have to run ‘sudo systemctl restart amidiminder’ manually to get devices connected. I’d be super grateful for some help :relaxed:

I just realized that it kinda works. I just need to turn off and on the midi controllers for the connections to update. Should it work without the rebooting of the midi devices?

I wonder if it should autorun ‘sudo systemctl restart amidiminder’ on boot so I would not need to run it manually or reboot the midi devices.

It’s better to try and figure out why is it getting disconnected. Are there any scripts or patchbox modules also starting up on boot?

Im not running any module on boot. No scripts either. Just few days ago I installed patchbox os. I haven’t added any scrips or turned on modules on boot. It’s a headless Pi booting to console.

I could start from fresh Patchbox OS image. Amidiminder is not embedded on Patchbox OS, right?

I’m hoping that installing it on fresh image of Patchbox OS
should work without wasting time on debugging this.

I only should then pull and install it from git and set my rules again then it should work?

Before starting fresh again, you could inspect the amidiminder service logs:

journalctl -u amidiminder

And look for anything suspicious. You may also save it to file and attach here for us to take a look:

journalctl -u amidiminder > amidiminder.log
1 Like