I am running the testing branch and I do have difficulties using the MIDI router. The problem is that the router only seems to link genuine raw MIDI devices, but does not create a mapping to non-raw output ports. This applies to ports mapped via the a2jmidid demon or my Android tablet. Although the ports are listed in the MIDI Ports part of the Web-UI, and they are enabled as Output ports, no mappings are created. Running jack_lsp -c confirms this.
Do your MIDI ports have spaces in their names?
Yes, the tablet for example appears as: a2j:SAMSUNG_Android (capture): SAMSUNG_Android MIDI 1
And the Arduino:
a2j:Arduino Leonardo (capture): Arduino Leonardo MIDI 1
The other oddity I am observing is that note events coming from the tablet are all translated to channel 1. Zynthians MIDI log shows correct incoming events for channel 5, but the output goes to 1.
Issue 392 describes this. Basically the Zynthian code makes an inappropriate assumption that it should convert underscores to spaces because earlier it converted spaces to underscores. This is plainly flawed as it does not handle mantra that have underscores in them to begin with.
Thanks a lot for the quick reply.
This must be a regression. I did not have that problem with the 2020 stable branch.
Can you show us the content of /etc/systemd/system/a2jmidid.service?
I have tweaked that one to list hardware ports and to suppress the unique identifiers because they change depending on position on USB hub etc. So I am running a2jmidid with the -eu option. The main Zynthian audio device is started with -X none. Basically I am not using raw MIDI because that blocks these ports to be used by ALSA sequencer ports. And on the jackd side jack_lsp lists raw MIDI ports all as system… without any hint to the actual hardware device behind them. The reason for this is that I am sometimes running my own routing scripts (based on mididings) because Zynthian does not allow device level MIDI routing (now).
I have done this kind of tweaking with “stable” and never had any problem.
That is what is breaking it ! We removed the -e option because of this exact issue. It was a bit of a work-around (to avoid fixing the code) as it gave us a quick fix.
I suggest you report the issues you have with testing without your manual tweaks, i.e. the issue that is causing you to make your tweaks.
Understand. The core issue for me was that I need to route MIDI between specific devices and there seems to be no easy command line solution for jack MIDI that identifies raw devices by a distinguishable name instead of “system”.
…I think I just discovered a solution for that problem. Jackd uses two set of names. The standard ones and so called aliases. With jack_lsp -c A I get all connections with the alias names included.
1 Like
You can route between specific devices using the webconf. I used it to map a din midi keyboard to a korg nts-1.
WHAT???!!!??? How do you do that? I can’t find it in webconf. Also, it probably does not allow discrete routing between engines and individual MIDI ports (which is an existing feature request).
Just found a solution to the MIDI device routing problem. Was easy to install via pip3. The nice thing is that the program supports regex and jackd alias names.
1 Like
Could you explain why do you need to route by hand? What are you trying to achieve? We could improve the zynthian auto-router to fit your use-case.
Thanks!
@jofemodo thanks a lot for asking.
One role of my Zynthian box is to act as a USB MIDI host for multiple synths and MIDI controllers. This makes it difficult to use Zynthians all inputs to all outputs routing as it creates loops.
Example: I want the Arturia Keystep to route to all other USB devices and want the Keystep get the MIDI returned from some of them. However, I do not want it to route to itself.
Another reason is that I want to be able to insert filters before or after specific MIDI devices. I do have a self made Arduino based synthesizer for example that works well with MIDI, but I do not want it to get MIDI clock as this causes unwanted load on the system.
My suggestion would be an option in the MIDI FX layers that allows one to choose the input and output ports in the same way as it can be done for audio FX layers.
I did something with MIDI filter rules, you can “Do things with ports”
I can’t see that. I can only see channel based rules
I don’t remember having implemented any port-related rule, but perhaps some kind of IA-thing on github has done the job 
Ah, I see, I just enabled it as a MIDI out in the MIDI ports section, so it accepts all messages from all places. As the NTS-1 only responds on one channel it’s pretty easy just to have it driven by one device / layer. Sorry for the confusion.
1 Like