Here is what that command returned.
I should mention that it appears that mono synths strictly stick on the root notes, while poly synths all appear to be sticking with all notes.
At first glance, it looks ok. But just in case, try running these commands, while mec & orac is already running:
aconnect -x
sudo systemctl restart amidiauto
And check for stuck notes, make sure to try to play the stuck notes themselves.
Ok. Gave that a whirl and things are still wonky. I did discover more about the peculiarity though. It would appear that (at least while using a poly synth such as analog style) The stuck note behavior only applies to single notes so if I hit and release 2 or more notes at the same time it behaves normally note on/note off, but when hitting a single note it sticks on every time.
Hey again, @Giedrius. I’m coming back to this again with hope of solving this time. I had a brief exchange with @thetechnobear about this issue. What he had to say was illuminating.
what looks to be happening is…
MEC is listening to MIDI events from the Push 2, so that it can interpret them, and send the right midi messages to pure data/orac.
but amidiauto is also connecting the Push2 directly to pure data…
this means Pure Data is getting both duplicated data, and also some data it’s not expecting.
It was pointed out that there was work done in the past around this developing some amidiauto rules applied through the .conf. I noticed that ORAC is packaged with that .conf file, but it doesn’t live in /etc/amidiauto.conf as expected. Is it possible that this issue is simply that amidiauto is not receiving the appropriate rules to cooperate well with MEC and ORAC?
Once the ORAC module is activated through patchbox, it changes the location of the rules file that amidiauto makes use of, check /etc/environment file, it should contain this line:
AMIDIAUTO_CFG=/usr/local/patchbox-modules/orac/amidiauto.conf
Also sudo systemctl status amidiauto:
patch@patchbox:~ $ sudo systemctl status amidiauto
● amidiauto.service - ALSA MIDI autoconnect daemon
Loaded: loaded (/lib/systemd/system/amidiauto.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-12-04 09:11:24 GMT; 1min 50s ago
Main PID: 24530 (amidiauto)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/amidiauto.service
└─24530 /usr/bin/amidiauto
Dec 04 09:11:24 patchbox systemd[1]: Started ALSA MIDI autoconnect daemon.
Dec 04 09:11:24 patchbox amidiauto[24530]: Reading rules in '/usr/local/patchbox-modules/orac/amidiauto.conf'...
Dec 04 09:11:24 patchbox amidiauto[24530]: Allowing '*' -> '*'
Dec 04 09:11:24 patchbox amidiauto[24530]: Allowing 'MEC MIDI' -> 'Pure Data'
Dec 04 09:11:24 patchbox amidiauto[24530]: Disallowing 'MEC MIDI' -> '*'
Dec 04 09:11:24 patchbox amidiauto[24530]: Disallowing '*' -> 'MEC MIDI'
Dec 04 09:11:24 patchbox amidiauto[24530]: Disallowing 'Push 2' -> '*'
Dec 04 09:11:24 patchbox amidiauto[24530]: Disallowing '*' -> 'Push 2'
To make sure Push2 is not connected to PD directly, you can run aconnect -lio and see the actual MIDI connections.
Okay. Did all of that and can wrap my head around everything except this:
As you can see here there is a client (130) that is among the connections, but which the readout does not name. So it looks like push 2 is indeed connecting directly to MEC and pd receives midi information from there, but also push 2 is connecting to 130 and pd is getting midi from there as well? Can you verify whether or not this 130 connection is potentially where the doubling of data might be coming from?
If I remember right, I’ve looked into this mystic client, it’s the aconnect process itself which runs temporarily to get the state of things, so it’s not duplicating the messages to PD.
Haven’t been able to generate a useful midi log yet, but in my poking around I noticed (as you can see here) MEC appears to have two outputs for midi both of which are going to pd one of which is going back to push 2. My wondering is that if this isn’t somehow a source of the mixup. Like the midi note on which is intended to be sent only back to the push to control the LEDs is instead getting sent also to pd. I’ve sent this question to Mark as well, but wanted to loop you in too in case you have any insights. Thanks
Indeed, it appears the undesireable connection is between MEC DEVICE OUT and pd. Mark says that the connections he has set are between MEC OUT and pd and MEC DEVICE OUT and Push2. Thus he says it is amidiauto that is creating this connection between device out and pd. It does appear that the amidiauto.conf is being read, but that the rules therein are somehow allowing this rogue connection to be established. Is there a new rule we might add to kill that connection?
Update: Finally solved! I added MEC MIDI OUT DEVICE -> Pure Data to disallow and changed MEC MIDI -> Pure Data to MEC MIDI OUTPUT -> Pure Data in the allow rules. This has totally solved the issue.
1 Like
Can you post the entire config file?
The MEC MIDI device names seem to have changed since the original version… I wonder why that happened.