Network UMP support in Zynthian is here

Software
21

@jofemodo There is a pending PR to use the Jack properties to set the port alias, it would be very interesting to have for remote device drivers… :slight_smile:

1 Like
22

I just merged your PR with the changes to jack connect for UMP.

Regarding the other “bigger” PR … please, split into 2 PRs. One with the ctrldev driver changes and another one with your git management proposal. The last one is quite critic and needs extra verification.

Thanks a lot!

2 Likes
23

Sorry for the confusion, I’ll fix the PR asap. And thanks for merging the other one! :clap:

24

BTW, the jacknetumpd version is also updated.

Regards,

2 Likes
25

Ready! This is the new PR:

Many thanks! :slightly_smiling_face:

2 Likes
26

Ohhh yes! It’s merged now!

Thanks @oscaracena !

2 Likes
27

Regarding UMP client integration, it would be nice to have the list of available “UMP devices” in the MIDI-OUT menu, like any other MIDI destiny. Same for MIDI-IN.
I mean, when a zynthian device has UMP enabled, everything should be transparent and easy.

The zynthian device see other UMP devices and can route MIDI to/from them. The zynthian device is seem by other UMP devices that can send/receive MIDI to/from it.

How do you see all this? I’m totally new to UMP and i don’t know what is the “spirit” behind, but it feels like it should be easy and straightforward. Indeed, it would be nice if each zynthian could “export” its chains and see other zynthian’s chains. Dreaming? :wink:

Regards,

2 Likes
28

I would expect UMP to present similar to USB MIDI due to its dynamic (hot plug) nature.

I have a Dev branch that allows zynthian to see other zynthians’ audio via AoIP and would expect UMP to be similar for MIDI. I haven’t had time to look at UMP yet.

1 Like
29

I know this thread is regarding netUMP, but thought it may be worth mentioning that i don’t think USB MIDI UMP for Midi 2.0 is enabled by default in the Raspberry PI OS kernel.
I don’t know if jack gets around this or not.
I rolled my own kernel to have a play, but frankly gave up when I couldnt get my Keystage to be recognised as a midi 2.0 device (although after doing a bit of research I don’t think it will at the moment)

30

Hi @BEB,

you’re the only person I know in the world who has experience with both Zynthian and BomeBox.

BomeBox has now officially released new firmware that supports MIDI 2.0 over the network, so I tried to see if it could detect the Zynthian – but I haven’t had any success so far.

I assume you’ll be at The NAMM Show 2026, where the BomeBox guys will also be. Could you try connecting Zynthian with BomeBox there and then share how to make it work? Thanks in advance.

1 Like
31

Hello Toff,

I will not be at the NAMM this year.

As far as I know, the BomeBox requires the remote device (Zynthian or anything else) to use mDNS to be detected automatically. The Network UMP daemon does not implement the mDNS service, that’s probably why the BomeBox does not detect the Zynthian.

But as mDNS support is optional (as said in the Network UMP specification), there should be a way to declare the Zynthian in the BomeBox using the IP address of the Zynthian (the UDP port is 5004). But I don’t know how to do this, you should ask directly to Florian (the man behind BomeBox :wink: ) using their support service

1 Like
32

Hi @BEB. Can you give us an update of the current state of MIDI 2.0 in linux and more specifically in zynthian?

1 Like
33

Hello @Riban,

sorry for the veeeerrrryyy long delay to answer, but I have had some very serious family issues who took all of my time since a few months.

To answer your question : MIDI 2.0 is now officially supported in ALSA, including the USB support. However, as far as I know, Network MIDI 2.0 is not yet officially implemented in ALSA. There are also a lot of discussion within JACK developers group, as we have found that JACK accepts MIDI 2.0 packets without any problems (for JACK, everything is just a stream of bytes, so MIDI 2.0 packets are made of chunks of 4, 8, 12 or 16 bytes which are handled perfectly by JACK. The issue is however how to tell to JACK’s clients if they receive MIDI 1.0 or MIDI 2.0. So right now, the discussion is about to keep JACK like it is for MIDI 2.0 - with the risk that you send MIDI 2.0 packets to a client which supports MIDI 1.0 only - or if a dedicated API is better, which would mean a new version of JACK with MIDI 2.0 “official” support)

MacOS 26.6 now supports officially Network MIDI 2.0. Apple has updated the MIDI Network applet (in Audio / MIDI configuration) so it supports both RTP-MIDI and Network MIDI 2.0. However, I have to say that there are still some issues with the driver (I am discussing every week with Apple developers about this within the MMA)

Windows support for MIDI 2.0 is still not official for public (you have to be part of the Win11 preview group to have the MIDI 2.0 service installed), but the latest tests made during the Superbooth a few weeks ago are very promising, as we were able to run heterogenous setup communicate altogether.

For now, if you want to use the Zynthian Network MIDI 2.0, I recommend you to use rtpUMP driver from KissBox (it is available for free and works on MacOS and Windows)

rtpUMP can communicated both in RTP-MIDI and Network MIDI 2.0 with the Zynthian (I recommend to use Network MIDI 2.0, as it uses less network resources than RTP-MIDI).

Note that I am working on a update of jacknetumpd, with a realtime thread implementation which gives much better timing capabilities when the Zynthian is heavily loaded.

Last thing (for the Zynthian developer team :wink: ) : ORAM menus use the name “NetUMP”, it should be replaced by “Network MIDI 2.0” which is the official name of the protocol

Benoit

6 Likes
34

Thanks @BEB for the response and I am very sorry to hear of your personal issues. I send you my best wishes.

I have been trying to understand the layers and thought there was not an official MIDI network transport layer. I now see that Network MIDI 2.0 is the preferred network transport layer for MIDI (1.0 & 2.0) and that RTP-MIDI should only be used for legacy support.

Although support is not fully operational in desktop OS, I would expect zynthian to be able to provide inter-zynthian network MIDI using this new (2024) protocol. I would expect to see all available zynthians on the network and be able to route between them. This would require:

  • Advertising and discovery
  • Session management
  • Data transport

We should add an option to enable Network MIDI 2.0 service.

It looks like we need to use mDNS + DNS-SD to discover devices on the LAN that support _midi2 service and present them in the list of MIDI input/output devices.

Session management is required to make the connections (route MIDI devices). We would use the same routing UI (enable MIDI input and output from and to a device) with the session management handling the actual connection/session. We should consider if and how to handle authentication (maybe as a later enhancement).

Data transfer would then use UMP.

We use JACK MIDI (with bridge to ALSA only where needed) so will benefit from resolution of the JACK integration of MIDI 2.0 but at the moment we don’t really have any MIDI 2.0 functionality so could possibly already get the MIDI 1.0 data over Network MIDI 2.0 transport, with consideration to how we support MIDI 2.0 messages.

I want to get the core functionality working (endpoint connectivity) but am particularly interested in seeing Flex Data Message transfer to see how we might integrate zynvoice with the MASSIG proposal for TTS transfer over MIDI.

Any pointers you can give on what tools already exsit in zynthianOS (Debian Linux) to facilitate these steps would be useful. I had a brief look at mDNS on zynthian and saw some of the _midi2 messages but have not yet had time to look in detail.

[Edit] I forgot that most of what I wrote is already implemented but discovery is not. I do not see any mDNS messages for _midi2 when jacknetumpd is running. @BEB @oscaracena is there a way to enable this?

3 Likes
35

Hi @riban

honnestly, I wrote ump_mDNS.cpp module in a quick and dirty way, because I wanted to demonstrate it on the MMA booth during the NAMM show in 2024 and I did not dig into it since this time :sweat_smile: (all my studio is built around static IP configuration and I don’t use mDNS, as I prefer to enter all addresses manually - just a personal taste)

I have made a test this morning with a fresh ORAM installation, and I saw that the mutlicast traffic was not going out of the Zynthian. I have to look in my notes, but I remember that there was something special to do to enable it (related to routes if I remember well)

I will try to take a look next week to that (that does not explain however the issue you have reported to my jacknetump git repo : the missing multicast route does not prevent a socket to be created and it seems that in your case, the OS does not accept to create the socket or something like that)

Benoit

2 Likes
36

Thanks Benoit.

If I could compile the source then I could help diagnose issues but I can’t (see issue on your github) and am snowed under with other commitments to work out the cause. Hopefully you find some time to figure out why mDNS/DNS-SD isn’t being transmitted and then I can add discovery to zynthian.

Cheers!

1 Like
37

Hi @Riban,

have you seen the note I have put in the git issue you created (about compilation issue) ?

I think you can 't compile the various external modules (from BEBSDK and NetUMP) because of a missing definition.

As you can see here in the README : GitHub - bbouchez/BEBSDK: Crossplatform C++ SDK used in various projects created by me · GitHub

you must have a define in your makefile depending on the target :

#define __TARGET_LINUX__ to compile the libraries under Linux

#define __TARGET_WIN__ to compile the libraries under Window

#define __TARGET_MAC__ to compile the libraries under MacOS

For Linux target (including the Zynthian), add -D__TARGET_LINUX__ in the makefile (you can see it in Makefile-Release.mk here jacknetumpd/jacknetumpd/nbproject/Makefile-Release.mk at main · bbouchez/jacknetumpd · GitHub which the makefile for Netbeans I use to compile jacknetumpd

Benoit

2 Likes
38

Hi @riban

did you manage to compile jacknetumpd by yourself ?

Benoit

39

Sorry, I am away on a business trip. I will try later this week.

40

I have not had any success. I do not understand how to build jacknetumpd from source. Can you provide some instructions? There are no makefiles (that I can find) or build instructions.