where should I find the log file?
Got it:
-- Boot 9940650adba14d5abf4edc3c636a3031 --
Feb 21 19:43:22 patchbox systemd[1]: Started ALSA MIDI minder daemon.
Feb 21 19:43:22 patchbox amidiminder[498]: reading rules from /etc/amidiminder.rules
Feb 21 19:43:22 patchbox amidiminder[498]: adding rule .hw --> .app
Feb 21 19:43:22 patchbox amidiminder[498]: adding rule .app --> .hw
Feb 21 19:43:22 patchbox amidiminder[498]: adding rule Axiom 49:0 --> Axoloti Core:0
Feb 21 19:43:22 patchbox amidiminder[498]: adding rule Axiom 49:0 --> Arturia BeatStep Pro:1
Feb 21 19:43:22 patchbox amidiminder[498]: adding rule Axiom 49:0 --> Arturia BeatStep Pro:0
Feb 21 19:43:22 patchbox amidiminder[498]: adding rule Arturia BeatStep Pro:1 --> Axoloti Core:0
Feb 21 19:43:22 patchbox amidiminder[498]: adding rule Arturia BeatStep Pro:0 --> Axoloti Core:0
Feb 21 19:43:22 patchbox amidiminder[498]: adding rule *:* -x-> RtMidiIn Client:*
Feb 21 19:43:22 patchbox amidiminder[498]: adding rule RtMidiOut Client:* -x-> *:*
Feb 21 19:43:22 patchbox amidiminder[498]: port added Arturia BeatStep Pro:Arturia BeatStep Pro Arturia Be [20:0]
Feb 21 19:43:22 patchbox amidiminder[498]: port added Arturia BeatStep Pro:Arturia BeatStep Pro BeatStepPr [20:1]
Feb 21 19:43:22 patchbox amidiminder[498]: port added Axoloti Core:Axoloti Core Axoloti Core [24:0]
Feb 21 19:43:22 patchbox amidiminder[498]: connecting Arturia BeatStep Pro:Arturia BeatStep Pro BeatStepPr [20:1] --> Axoloti Core:Axoloti Core Axoloti Core [24:0], by rule: Arturia BeatSt>
Feb 21 19:43:22 patchbox amidiminder[498]: connecting Arturia BeatStep Pro:Arturia BeatStep Pro Arturia Be [20:0] --> Axoloti Core:Axoloti Core Axoloti Core [24:0], by rule: Arturia BeatSt>
Feb 21 19:43:22 patchbox amidiminder[498]: port added Axoloti Core:Axoloti Core Axoloti Core [28:0]
Feb 21 19:43:22 patchbox amidiminder[498]: connecting Arturia BeatStep Pro:Arturia BeatStep Pro BeatStepPr [20:1] --> Axoloti Core:Axoloti Core Axoloti Core [28:0], by rule: Arturia BeatSt>
Feb 21 19:43:22 patchbox amidiminder[498]: connecting Arturia BeatStep Pro:Arturia BeatStep Pro Arturia Be [20:0] --> Axoloti Core:Axoloti Core Axoloti Core [28:0], by rule: Arturia BeatSt>
Feb 21 19:43:22 patchbox amidiminder[498]: port added Midi Through:Midi Through Port-0 [14:0]
Feb 21 19:43:22 patchbox amidiminder[498]: port added Arturia BeatStep Pro:Arturia BeatStep Pro Arturia Be [20:0]
Feb 21 19:43:22 patchbox amidiminder[498]: port added Arturia BeatStep Pro:Arturia BeatStep Pro BeatStepPr [20:1]
Feb 21 19:43:22 patchbox amidiminder[498]: port added Axoloti Core:Axoloti Core Axoloti Core [24:0]
Feb 21 19:43:22 patchbox amidiminder[498]: port added Axoloti Core:Axoloti Core Axoloti Core [28:0]
Feb 21 19:43:34 patchbox amidiminder[498]: port added RtMidiIn Client:TouchOSC Bridge [130:0]
Feb 21 19:43:34 patchbox amidiminder[498]: port added RtMidiOut Client:RtMidiIn Client:TouchOSC Bridge 130:0 [131:0]
Feb 21 19:43:34 patchbox amidiminder[498]: observed connection "RtMidiOut Client":"RtMidiIn Client:TouchOSC Bridge 130:0" --> "Arturia BeatStep Pro":"Arturia BeatStep Pro Arturia Be"
Feb 21 19:43:34 patchbox amidiminder[498]: observed connection "RtMidiOut Client":"RtMidiIn Client:TouchOSC Bridge 130:0" --> "Axoloti Core":"Axoloti Core Axoloti Core"
Feb 21 19:43:34 patchbox amidiminder[498]: observed connection "RtMidiOut Client":"RtMidiIn Client:TouchOSC Bridge 130:0" --> "Axoloti Core":"Axoloti Core Axoloti Core"
Feb 21 19:43:34 patchbox amidiminder[498]: observed connection "RtMidiOut Client":"RtMidiIn Client:TouchOSC Bridge 130:0" --> "RtMidiIn Client":"TouchOSC Bridge"
Feb 21 19:43:35 patchbox amidiminder[498]: observed disconnection Arturia BeatStep Pro:Arturia BeatStep Pro Arturia Be [20:0] --> Axoloti Core:Axoloti Core Axoloti Core [24:0]
Feb 21 19:43:35 patchbox amidiminder[498]: observed disconnection Arturia BeatStep Pro:Arturia BeatStep Pro Arturia Be [20:0] --> Axoloti Core:Axoloti Core Axoloti Core [28:0]
Feb 21 19:43:35 patchbox amidiminder[498]: observed disconnection Arturia BeatStep Pro:Arturia BeatStep Pro BeatStepPr [20:1] --> Axoloti Core:Axoloti Core Axoloti Core [24:0]
Feb 21 19:43:35 patchbox amidiminder[498]: observed disconnection Arturia BeatStep Pro:Arturia BeatStep Pro BeatStepPr [20:1] --> Axoloti Core:Axoloti Core Axoloti Core [28:0]
Feb 21 19:43:35 patchbox amidiminder[498]: observed disconnection RtMidiOut Client:RtMidiIn Client:TouchOSC Bridge 130:0 [131:0] --> Arturia BeatStep Pro:Arturia BeatStep Pro Arturia Be [2>
Feb 21 19:43:35 patchbox amidiminder[498]: observed disconnection RtMidiOut Client:RtMidiIn Client:TouchOSC Bridge 130:0 [131:0] --> Axoloti Core:Axoloti Core Axoloti Core [24:0]
Feb 21 19:43:35 patchbox amidiminder[498]: observed disconnection RtMidiOut Client:RtMidiIn Client:TouchOSC Bridge 130:0 [131:0] --> Axoloti Core:Axoloti Core Axoloti Core [28:0]
Feb 21 19:43:35 patchbox amidiminder[498]: observed disconnection RtMidiOut Client:RtMidiIn Client:TouchOSC Bridge 130:0 [131:0] --> RtMidiIn Client:TouchOSC Bridge [130:0]
lines 2956-3008/3008 (END)
Ok, we see it notices the disconnections, something must be executing something like aconnect -x that disconnects everything. It might be a patchbox module or something else.
What’s the output of:
systemctl status patchbox-init
Also, what’s the output of:
cat /etc/environment
systemctl status patchbox-init:
Feb 22 17:02:39 patchbox systemd[1]: Started Patchbox Init.
Feb 22 17:02:39 patchbox patchbox[795]: 2023-02-22.17:02:39: Pisound MIDI device not found!
Feb 22 17:02:39 patchbox patchbox[795]: 2023-02-22.17:02:39: Blink.
Feb 22 17:02:39 patchbox patchbox[795]: 2023-02-22.17:02:39: Killing all Pure Data instances!
Feb 22 17:02:39 patchbox patchbox[809]: puredata: no process found
Feb 22 17:02:39 patchbox patchbox[795]: 2023-02-22.17:02:39: Done, flashing LEDs.
Feb 22 17:02:39 patchbox patchbox[795]: 2023-02-22.17:02:39: Blink.
Feb 22 17:02:39 patchbox patchbox[795]: 2023-02-22.17:02:39: Blink.
Feb 22 17:02:39 patchbox systemd[1]: patchbox-init.service: Succeeded.
Feb 22 17:02:39 patchbox systemd[1]: patchbox-init.service: Consumed 1.136s CPU time.
cat /etc/environment:
JACK_PROMISCUOUS_SERVER=jack
PATCHBOX_MODULE_ACTIVE=/usr/local/patchbox-modules/puredata/
Run patchbox module deactivate, it should sort this out.
It did fix it. What if I want autorun pd patches headless?
Is it possible to autoconnect midi devices to RtMidiIn Client:TouchOSC.
Im trying but I cant get the rule to route the connection. Everything else is working with the touchOSC.
I just need to route manually the devices via aconnect Gui after booting. And I really would like to just create rule for it to be done with Amidiminder.
reading rules from /etc/amidiminder.rules
adding rule .hw → .app
adding rule .app → .hw
adding rule Axiom 49:0 → Axoloti Core:0
adding rule Axiom 49:0 → Arturia BeatStep Pro:1
adding rule Axiom 49:0 → Arturia BeatStep Pro:0
adding rule Arturia BeatStep Pro:1 → Axoloti Core:0
adding rule Arturia BeatStep Pro:0 → Axoloti Core:0
adding rule Arturia BeatStep Pro:0 → RtMidiIn Client:0
adding rule 132:0 → 131:0
adding rule : -x-> RtMidiIn Client:*
adding rule RtMidiOut Client:* -x-> :
patch@patchbox:~ $ aconnect -i -o
client 0: ‘System’ [type=kernel]
0 'Timer ’
1 'Announce ’
client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 20: ‘Axiom 49’ [type=kernel,card=1]
0 ‘Axiom 49 Axiom USB Out’
1 ‘Axiom 49 DirectLink Out’
2 ‘Axiom 49 Axiom Ext In’
client 24: ‘Arturia BeatStep Pro’ [type=kernel,card=2]
0 ‘Arturia BeatStep Pro Arturia Be’
1 ‘Arturia BeatStep Pro BeatStepPr’
client 28: ‘Axoloti Core’ [type=kernel,card=3]
0 ‘Axoloti Core Axoloti Core’
client 32: ‘Axoloti Core’ [type=kernel,card=4]
0 ‘Axoloti Core Axoloti Core’
client 131: ‘RtMidiIn Client’ [type=user,pid=800]
0 'TouchOSC Bridge ’
client 132: ‘RtMidiOut Client’ [type=user,pid=800]
0 ‘RtMidiIn Client:TouchOSC Bridge 131:0’
I wonder if I have wrong rules for the TouchOSC
I just want the Beatstep Out to go to TouchOSC bridge.
I got it working, just had some wrong Rules 
Sorry for hyperactive forum behavior 
It shouldn’t be running aconnect -x on Patchbox OS - could you check the output of these commands:
cd /usr/local/pisound/
git status
A note if you are using amidiminder with Midihub:
After the latest Midihub firmware update, the amidiminder rules I had created for Midihub no longer functioned.
Originally, Midihub usb midi ports would be specified as “Midihub : MIDI [1-4]” etc, but after the update, the aconnect list suggests that MIDI 1-4 is no longer how the individual usb connections are referenced. But they can be referenced by using 0-3.
So, in my rules, the connection “Nymphes : * <— Midihub : MIDI 2” (for example) now reads “ Nymphes : * <— Midihub : 1”
This fixed the issue.
This is very curious! The two forms:
- Midihub : MIDI 2
- Midihub : 1
have always meant the same thing!
The first form is doing a partial match on the name of the port, which for Midihub (at least in the past), came up as ‘Midihub MH-1Z109TZ MIDI n’ where n is 1 through 4.
The second form is using the port number assigned by the kernel, which is just a number starting at 0, so for Midihub, 0 through 3.
So I understand why the second form works… what I don’t get is why the first no longer works.
When I run aconnect -l on my system with my Midihub (non firmware upgraded), I get this in the output:
client 36: 'Midihub MH-1Z109TZ' [type=kernel,card=5]
0 'Midihub MH-1Z109TZ MIDI 1'
1 'Midihub MH-1Z109TZ MIDI 2'
2 'Midihub MH-1Z109TZ MIDI 3'
3 'Midihub MH-1Z109TZ MIDI 4'
The 36 may be different on other systems, but the four ports I’d expect to be the same everwhere.
@KyleMc , I’d be really interested to learn what aconnect -l output for the Midihub on your system.
aconnect -l:
client 0: ‘System’ [type=kernel]
0 'Timer ’
1 'Announce ’
Connecting To: 128:0
client 14: ‘Midi Through’ [type=kernel]
0 ‘Midi Through Port-0’
client 16: ‘Midihub MH-0918CGV’ [type=kernel,card=0]
0 ‘Midihub MH-0918CGV Midihub MH-0’
1 ‘Midihub MH-0918CGV Midihub MH-0’
Connecting To: 20:0
Connected From: 20:0
2 ‘Midihub MH-0918CGV Midihub MH-0’
Connecting To: 24:0
Connected From: 24:0
3 ‘Midihub MH-0918CGV Midihub MH-0’
client 20: ‘Nymphes’ [type=kernel,card=1]
0 'Nymphes MIDI 1 ’
Connecting To: 16:1
Connected From: 16:1
client 24: ‘MIDI USB-USB’ [type=kernel,card=2]
0 ‘MIDI USB-USB Puerto 1’
Connecting To: 16:2
Connected From: 16:2
1 ‘MIDI USB-USB Puerto 2’
2 ‘MIDI USB-USB Puerto 3’
3 ‘MIDI USB-USB Puerto 4’
I suspected that it was always the case that I could use the port identifiers 0-3, but I preferred the MIDI n signifier as it was a more apt description. I’m thinking now, perhaps, something went awry with my firmware update.
By the by, my OS is Raspian.
*Edited to show aconnect -l results with Nymphes powered on
Curious!
Linux does some awful stuff with the simple port names that USB MIDI devices supply, like splicing the device name in front of the port name (sometimes twice!) for no apparent reason. In this case, there appears to be some truncation going on… like the kernel wanted to make the name “Midihub MH-0918CGV Midihub MH-0918CGV MIDI 1”, but that was too long.
@Giedrius - Why does the device name for the Midihub include ‘MH-xxxxxx’? And what are the signifiance of those numbers. Also, it clearly makes the name long, and the port names even longer!!
@KyleMc - Is your system language set to Spanish? I’m curious where the name ‘MIDI USB-USB Puerto 1’ came from!
I’m interest in all this as this isn’t the first piece of software that has had to deal with the bizarre naming of MIDI ports that happens (not just in Linux, but also Mac, Android, & Windows).
“MIDI USB-USB” is referencing a device that connects USB Midi Hosts- which is produced by a small business in Spain:
https://sevillasoft.com/index.php/midi_usb-usb/
Edit: I realized that my answer was somewhat ambiguous. My system is set to English. The Spanish reference to “Puerto n” is from the aforementioned device which was made in Spain.
This is the serial number of the device. It is very significant in cases where you have more than one Midihub connected to your system, so you can easily differentiate between the units and have consistent rules.
Fortunately, you are not required to provide ALSA with the entire name, I would suggest using names such as:
Midihub MH-0918CGV:0for the USB A port.Midihub MH-0918CGV:1for the USB B port.Midihub MH-0918CGV:2for the USB C port.Midihub MH-0918CGV:3for the USB D port.
You may even use Midihub:0, but it would be problematic if you have more than one unit connected to the system.
Different OSes format the names in wildly different ways, the current one is the best we can do across the Windows, Linux and macOS. The device does not know which OS is hosting it and it provides the same USB string identifiers for any OS.
Also, if you change the USB port names in the Editor, and reconnect it to the system, the aconnect -l output would change.
1 Like