Distributing MIDI over IP with zynthian

[wyleu]

I’m thinking about how you would want to a implement a simple MIDI QMIDINET like interconnection system for zynthians and external PC’s?
Configured via a web interface, and enabled and disabled in control panel.

It seems a good level of abstraction to put in. I doesn’t strike me as too difficult to do, As the QMIDINET et al. does all the transport stuff reliably.

So we would have on zynthian start . . .

1. Port generation on devices
2. Checking for created ports in interconnect default routing table.
3. load default routing table. tying up the virtual ports to the zynthian and local MIDI in’s and outs.

Very handy for multiple zynthian rigs.
I’m keen to do this myself but I’d like to have your opinion before I start, and your recommendation of who else to discuss it with, before I stick up a proposal on the forum.

[christianforshaw]

Do you mean something like a cluster… So there will be more cpu etc

[mheidt]

I am working on this one soon btw

Issue: Midi-Profiles

[wyleu]

Ok.

I now have an interesting little setup running…

Which is passing MIDI over IP using multimidicast, a2jmidid -e & bit of patching in qjackctl via a remote shell… .

So on a remote machine connected only via wired ethernet and an Ethernet Hub I can get, using aseqdump and a bit of aconnect I can display the MIDI data coming out of zynthian. . . .

So to give a little detail.

There is a generally agreed way to pass MIDI across Ethernet (IP) networks and it grew out of some Windows stuff. . . .(http://nerds.de/) .
The UDP based protocol was supported on linux by QmidiNet(https://qmidinet.sourceforge.io/) which is what you would use on a desktop machine because it uses the XWindows infrastructure to display a tiny little system icon . . . .

It’s the one between the two arrows and the battery . . .

So because of that, it won’t run on a zynthian.

Luckily our friends in the lighting world (which uses MIDI but calls it DMX) have got a stripped down version that just uses a command line, so will run in our rarefied community.

multimidicast

Which is good.

So what are we actually doing here? Well we are opening up a range of IP linked MIDI ports on two different machines that will appear as ALSA MIDI devices to anything that generates and receives MIDI.

But something has to route the MIDI between devices and most applications have some way of doing this …
once you have got QmidiNet running on your desktop linux machine ( It could probably be a Pi althou I’m using an old 32 bit laptop) you can see the ports in something like MidiEditor…

The local QmidiNet instance is in my case set to 4 ports under the options menu in the Icon… ( ok so it’s not completely irrelevant).

On the Zynthian
You will have to log on via a remote ssh shell.
from your desktop machine

ssh -X root@zynthian.local

Download the files (http://llg.cubic.org/tools/multimidicast/) expand them and then run the make file to build the code for your Broadcom architecture ( This is why you couldn’t copy the file around like a .exe in windows, You might not be using the same processor).
Once it’s run make it will generate a runnable file called multimidicast which you run by going into the directory and typing ./multimidicast&

This will build 20 Network MIDI ports on the zynthian, which will auto connect themselves to the 4 ports on your desktop machine.

I really useful couple of commands at this point are run in terminals on either machine and display helpful information . …

aconnect -l
aconnect -lo
aconnect -li

which display alsa MIDI ports for input and output

and:

aconnect 130:0 128:0

which actually connects the qmidinet port 13):0 to 128:0 which is the other useful command aseqdump which displays MIDI date received on a alsa MIDI port as in the picture at the top of this post . … .

So this is great apart from one thing… ALSA & JACK. The Zynthian world uses JACK2 whilst all this network stuff is ALSA based.
Basically there are two different world and the aconnect trick on the zynthian will ‘see’ the midi ports but it wont be able to join then to anytihng zynthian like cos they are all in the Jack world… Don’t you love technology.

Luckily there is a bridge to cross this great divide . it’s called

a2jmidid

and it should already be on your zynthian as part of the jack installation (correct me on this if you know better) .

You run it on the zynthian with

a2jmidid -e &

The & run’s it in the background…

Now we can use one of the great ssh feature. … when we ran ssh to log onto the zynthian we specified -X this allows ssh to run XWindows programmes over the ssh pipe…

So you can now type

qjackctl &

into the ssh shell and you will see…(eventually it can take a little time …)

Pressing Connect brings up . . . .

In this window connect the Zyncoder output to the multimidicast playback Port 01 and you should be seeing MIDI notes played by the Zynthian appearing on your remote machine in the aseqdump window…

Enjoy!

p.s.The stuff above was done using the USB connected AKAI MPK. The direct connection from the Nord MIDI OUt to Zynthian MIDI IN was patched but seems to be not working in my case. Good MIDI data going into Zynthian …
I have tried getting data out of the tty port ( the Hard wired Zynthian MIDI port ) but all I get instead of notes as I should is the occasional Clock, Active Sensing and stop messages with occasional other garbage… I can’t use the MIDI IN port anyway on this zynthian ( It did work originally) feature, error bad plumbing …?
I have had a little encoder chatter on the LS knob which has connections on the sub board and relocating they wires internally fixed that so perhaps it’s wiring related but I’d like to know if it’s a known issue, or am I just slowing everything down with all this network stuff? The USB port works fine.

[wyleu]

Update on the MIDI IN Issue described above…

In /boot/config.txt . . . . .

Adjust Serial Port Clock to allow MIDI baudrate 31250

init_uart_clock=2441000
init_uart_baud=38400
dtparam=uart0_clkrate=3000000

[wyleu]

Now we can have a little fun with Jack MIDI.
Cos jack has a Python interface and it’s worth a little look. . . .

https://jackclient-python.readthedocs.io/en/0.4.2/

so ssh onto the zynthian from your remote host

ssh -X root@zynthian.local

and fire up python 3

python3

now type

import jack
client = jack.Client('WyleuClient')
     
for port in client.get_ports(is_midi=True):
         print(port,client.get_all_connections(port))

and you get a list of all the Jack MIDI ports and what they are connected to . . .

This would appear to be screaming out for an visual interface on the web client . . .

I’ll have a little play . . .

[smespresati]

Hi @wyleu,

I’m curious about your “research”. Was your target to send MIDI data over the network (wired or wireless) from a computer to the Zynthian box? If I understood well you managed to do it using a Linux computer, am I right?

Your explanation about the research is quite clear, however there are things about how to use that is not so easy to understand (at least for me). Once the software is installed and configured…how to map midi channel/engine/instrument to de Zynthian’s IP in order to be used for the linux computer? What about latency?

Regards, Jose

[wyleu]

Thank you for describing my explanations as clear. That feels nice.

Your first and last questions.

• Was your target to send MIDI data over the network?
  Yes, certainly. I wanted to be able to communicate with the zynthian over IP networks. I’ve done this before and have found MIDI over (wired) IP to be very good. I haven’t measured the latency, contenting myself with using my ears. But I did find a video on-line of Billy Joel’s keyboard player and he says it’s fine to use MIDI over IP, his rig runs on it. So I trust the hardware.

My personal drive is to record and play from MIDI sequencers like MIDI editor from any keyboard I can attach a zynthian ( or simply a raspberry pi) to. The MIDI over IP(UDP) is agnostic, it will work with Windows implementations ( and I assume MAC’S, please tell me if you know…)
So it should be able to present MIDI data from the zynthian without it having to be rendered out to a hardware MIDI port and sent over MIDI cables. IN effect you get the functionality of a MIDI Junction box for free on the IP network by choosing which ports connect to what.

• how to map midi channel/engine/instrument to de Zynthian’s IP in order to be used for the linux computer
  Mapping on the Zynthian is what I’m looking at at present. You could use qjackctl files to store the configurations, but I’m intrested initially in simply reading and displaying the present configurations as read by the python jack interface as I’ve listed above.

I think there is a fairly simply touch screen interface to be written that displays the current setting. Remember you want it to be accurate so it’s best to get the connections live and display them so that when new devices like usb midi ports are plugged in and unplugged the display reflects these changes.
I would see that being something on the Setup Menu in a similar style to the conventional displays.

This is a different issue to the over Network issue. Certainly The network ports if present would be detected and added to the display. But this display is really about allowing allocation of MIDI channels in zynthian to MIDI channels on the various inputs.
I think this is important because the issue of selecting differing MIDI output channels on Keyboard controllers is a right pain. The Roland Master Keyboard, always comes up in MIDI channel 1 as does the AKAI MKS. So The patching want’s to be set on the zynthian on the way in and stored so the setup can be recalled and displayed.

We would want to allocate the inputs for the two different controller keyboards to any or all of the zynthian Layers.

So the Roland Master keyboard can play a piano and the AKAI can play a synth line.

I’m fiddling with screen layouts at the moment ( Anyone know of a good TK/SVG python library…
It might well be as simple as rendering a PNG file every time the jack setup changes.
IMHO, There wants to be similarish appearances for the web interface and the touchscreen .

Embedding events to do things would come after that.

How this then get’s connected so a remote keyboard can be mapped into the MIDI MIX, would probably be the next issue. So that the separately connected Nord zynthian and indeed the Nord itself could be controlled and configure via the zxynthian interface.
A Bit like couplers on Church organs.

Just a note on Zynthian reliability.My hifi berry amp+ zynthian is driving the HDMI display and has been connected to the Roland Master keyboard, It’s been A perfect piano for about six months now and survives everything we throw at it. Once people knows where the volume control the just don’t even know or care what is doing the work and it’s not failed once.

The joy now is I can record and playback MIDI from all the keyboards at my linux laptop. Which is great for rehearsals and practices.

[mheidt]

As I quoted above. I am working on parts that might help you.
Regarding master keyboard and channel 1, the new midi filter engine can translate midi messages.

[wyleu]

Forgive my exuberance!
This is really about identifying the components of a zynthian MIDI Network.
In effect it’s the ability to easily allocate a zynthians’s network connection to any available multimidicast port pair, upon a particular IP Net.
It’s possibly nothing more than Network Enable/Disable in the Web Conf and and selector to choose which Net bus you want the zynth on.

[mheidt]

If I understand correctly, we need to compile multimidicast for the raspberry.
If @jofemodo decides to integrate it, I can take care of that switch and the integration of the new midi ports in the webconf.

[wyleu]

Yes it just involves downloading and typing make.

The 20 port setting is hard coded.

A (polite) suggestion for machine identification . . . .

[ssj71]

It looks like you’re already pretty far down this path, but I would have reached for OSC for any networking of midi. I wrote OSC2MIDI for exactly this sort of thing (sorry for the shameless plug) https://github.com/ssj71/osc2midi . I don’t know if that’s helpful at all at this point, but its another option that could be considered.

[wyleu]

What’s been done is probably nothing more than a test of technology, so ANY information in the area is of great interest and precisely why the exercise was publicised.

The more devices we can place a Zynthian next to the better! Conceptually we are declaring an out of band management channel, so we have to provide:-

1. A Config frontend to connect to and from and disable that external management channel.
2. A startup mechanism for any or all of the components required to implement the Network side of the management channel.
3. Storage and restoration of user preferences mindful of issues like USB plug and play with all the current movement of jack components associated with such an action.

OSC seems to offer several very attractive features, sync’d events across implementations would seem to lend itself to zynth nests of eager users for instance.

The ease of use of the Laptop end that connects into the management channel is probably the users are of most configuration hell. Depends a bit on what might get connected.
As presently envisaged, The Management channel will simply present, on a selectable interface, one of 20 MIDI qnet channels.
OSC could easily be an option ( subject to the ZDFL approval, OBVIOUSLY…)

Now if it could be demonstrated that OSC could completely encompass that functionality then it would be other obvious way to go. Proper naming would be a nice to have.

Do we need to provide an external time reference for Zynthians if we network with OSC?

I like the idea of communicating intelligently with Kyma!

[jofemodo]

Currently Zynthian supports TouchOSC, that is a kind of MIDI over OSC. You can enable from admin menu in your Zynthian Box. After that, you can use any TouchOSC-enabled controller to control your zynthian.

I’ve tested using MyOSC app from my mobile phone and it works like a charm

Also, the latency is quite acceptable, moreover if you create a direct link without passing thru the router (enable Wifi Access Point feature in your mobile).

Regards,

[wyleu]

I have seeveral components of the midi-netwrok element constructed but I’m not sure quite where they should go and how they are run.

1. I have a recipe .sh file that will make the the multimidicast executable and copies it to /usr/local/lib

2. I have a service file that starts the multimidicast service which I believe should be located in /etc/systemd/system

I’m not sure about.

How to start and stop the service under programme control from the webconf gui, and how this all hooks together with the jack/alsa issues.

I’m also rather confused about simple git issues I have already blown away several versions of this whilst attempting to merge and am nervous about making pull requests whilst I’m doing this sort of thing.

I’m worried about preventing the zynthian from running because there is no IP netwrk for instance.

[jofemodo]

Hi @wyleu!

Have you made some advance with the MIDI over network configuration? Webconf part is almost ready and i will be very happy of tweaking with the systemd scripts for starting the thing.

Regards!

[wyleu]

Sorry I’ve just started a new job so have been a bit distracted.

I put together an install script . . . install_multimidicast.sh (275 Bytes)

Which I assume goes in /zynthian/zynthian-sys/scripts/recipes/

There is the systemd script . . .

midi-network.service (269 Bytes)

which needs to be started and stopped depending on the settings of the network env variables and webconf.

Then there is the MIDI connector bit that wires all this into the a2jmidid components…

I’m sorry this has dragged I’ve had a monitor fail and I’ve had to update the HIfiberry Amp…

If there is anything I’ve forgotten please remind me.

[Mister_Carrington]

May be this tiny box will solve your interconnections?

http://www.sevillasoft.com/news.php

I’m using it to solve some USB issues because differents computers and controllers.

[jofemodo]

Nice device!

I just commited a bunch of changes to the repositories that try to address this use case (MIDI-host).
I will comment this update in a separate post

Regards,