Looks like my issue is with IPv6. Somehow Avahi advertises RTP-MIDI with both v4 and v6 IPs. Mac tries to use the v6, but jackrtpmidid does not liston on v6.
I can make it work by disabling IPv6 at the avahi-daemon level, but… @BEB@jofemodo Would it make sense to try porting jackrtpmidid to IPv6?
Indeed… a bit of googling turns up a lot of references to “_apple-midi._udp” and none at all to “_rtpmidi._udp”, both in source code, documentation and hardware (iConnectivity devices advertise and look for this)
@jofemodo, where does the current name come from? _rtpmidi looks saner of course, but it’s not much use if nothing looks for that
According to avahi-service(5) it defaults to advertising on both IPv4 and v6, and if jackrtpmidid doesn’t listen on v6 then it shouldn’t be advertising it. Adding this to the rtpmidi avahi service should do the trick without affecting other services:
<service protocol="ipv4">
I can’t test IPv6 but if you can confirm that fixes it, I’ll add this to my pull-request.
When i wrote the Avahi service definition file i invented this name “_rtpmidi” , and forgot to do some research, thinking (wrongly!) that the port number will be enough. But now your PR is merged and the problem fixed
The syntax is, being XML, picky… one can’t just add such a line in there (as I suggested), you need to change the existing <service> line to include the protocol info. Submitted another PR for it: https://github.com/zynthian/zynthian-sys/pull/181
I can’t tell if it makes sense to have IPv6 support in RTP-MIDI. I am working with RTP-MIDI devices since more than 10 years, and I got something like maximum 2 or 3 requests in this whole period to have IPv6 compatibility.
Technically, it is not a very big deal to do it (Linux stack does most of the work, as long as you change the Posix calls) but I am not convinced it is worth the effort (especially if you consider that most of existing RTP-MIDI hardware products do not support IPv6, so finally only a limited subset of devices will be able to be used in this configuration)
A bug in the RTP-MIDI driver on the Mac… Noooo… I can’t believe it
Honnestly, I still wonder how it is possible that this driver is not perfectly stable after all this time. There are still many things not working properly on the Mac RTP-MIDI driver (I recently discovered that some options in the Control Panel do not exist in all versions! )
in fact, there is a reason for the service to be called “applemidi” and not “rtpmidi”. The session control protocol is not a part of the official RTP-MIDI specification (RFC6295)
The RFC document does not clearly specify what protocol must be used to manage sessions between RTP-MIDI devices, it only suggests SIP and SDP, which are pretty heavy to implement and can lead to many compatibility problems.
So Apple created a session protocol which became the “de-facto” standard. That’s why Wireshark has two filters : one is “applemidi” and the other is “rtpmidi”. The first filter looks for Apple session messages (but not the MIDI messages) and the second one looks for RTP-MIDI messages (as described in RFC6295)
So, since Bonjour advertises in fact the ports used by the session protocol (and not the RTP-MIDI ports, which are hidden by the session protocol), the mDNS service was named “applemidi”. That’s also the reason so many people think that RTP-MIDI and AppleMIDI is the same thing (which is not)
@BEB Thanks for the feedback. I tried to port jackrtpmidid to IPv6. Here is the pull request: https://github.com/imodularsynth/jackrtpmidid/pull/1. It seems to work now with both IPv4 and IPv6. There is still a bug in “MIDI Network Setup” if one tries to connect with a manually entered IPv6 address, but it works with the advertised service.
thank you for adding this to the RTP-MIDI daemon. I have merged your commit with the original code on Github. You are now officially part of the project
What is has indicated is quite how crazy people get with this kit. . . ! As ever way beyond any of our simple technical minds.
I was involved with the qmidinet implementation, and it just kind of works in that world.
Turn it on and you can see lots of machines and I tend to operate a pool of 16 MIDI machines to try and keep it all sane.
Get’s the occasional MIDI howl around and keyboard stick ( keep the panic switch handy!) but that’s really a flaw in MIDI. Machines don’t really have a sense of keep making this noise for ever as an annoying concept.
How involved should the RPT-MIDI get? I sense that it’s seen more as a method of controlling a device remotely, and seems like a prevalent layer in the Apple Audio world ( A universe of caves down in the zynthian basement whose door I haven’t opened yet… I hear there’s a perfumed garden down there, but I’m not sure I believe it ! )
But someone will demonstrate it !!
The original idea was using audio clips as evidence of a fix. We had some early noise in the system and the audio recorder was a good way of proving things worked and it grew from there.
It’s something that once again might well be operateed over a MIDI network. There is a bit of work going on around remote control messaging ( qwerty & MIDI ) that might also be of RTP-MIDI & qMIDINet interest.
, and forgot to do some research, thinking (wrongly!) that the port number will be enough. But now your PR is merged and the problem fixed 
(sound clip from a Zynthian)?
)