[LAD] MIDI-2-TCP, TCP-2-MIDI

christoph.kuhr at web.de christoph.kuhr at web.de
Wed Aug 29 20:33:24 CEST 2018


Hi !
I would always prefer a UDP based solutions,  because TCP can really mess up the timing. UDP packetloss usually is below 1%. The bigger problem in this case are WIFI connections, scrambled packet orders and jitter.
Are there any objections to using Open Sound Control based solutions?
To me it makes more sence, because it is an IP-based protocol (32 bit) in contrast to MIDI, which is designed for 8 bit serial interfaces.
A basic MIDI OSC gateway is available here:
https://launchpad.net/oscmidi
Further more, you could use it to control OSC enabled applications like Ardour and provide some customized control mappings.
I wanted to start some extension development on this myself for the public internet (unicast).
Perhaps we can align some effort on this?
I already did a specialized Sysex gateway with OSC which is absolutly relyable. (Remote control of two Yamaha mixing desks).
BR,
Ck Mittwoch, 29 August 2018, 06:18nachm. +01:00 von Len Ovens  len at ovenwerks.net :

>On Wed, 29 Aug 2018, Jonathan E. Brickman wrote:
>
> I need lossless JACK MIDI networking outside of JACK's built-in networking, and
> not multicast unless someone can tell me straightforwardly how to get multicast
> (qmidinet) to run within localhost as well as outside it. Thus I am thinking of
> trying my hand at using the Mido library to bridge JACK MIDI and TCP. I have
> never done this sort of coding before, programmatorially I am mostly a deep
> scripting guy, Python-heavy with a bunch of Bash on Linux, Powershell-heavy on
> Windows of late, with a pile of history on back in Perl on both and VBA on
> Windows. Anyone have hints...suggestions...alternatives...a best or better
> starting place? Right now I don't want the applets to do GUI at all, I just want
> them to sit quietly in xterms, on JACK servers, keeping connection, and passing
> MIDI data to and fro, as other processes and devices bring it.
>
>While I have not had any issues with qmidinet, it is not immune to packet 
>loss. If you want a place to start I would suggest rtpMIDI would do what 
>you want and be a great service to the linux community. While there have 
>been in the past rtpmidi implementations in Linux, they seem to have 
>suffered bitrot and in fact I don't even know if the source is still 
>available.
>
>https://en.wikipedia.org/wiki/RTP-MIDI#Linux
>
>They mention Scenic, but anything I tried with that (like building from 
>source) did not work. (it has been 1 or 2 years since I tried) The full 
>implementation at least guarantees all note off events make it through. 
>There was a google repo called MIDIKIT, but google has shut all that stuff 
>down. I don't know if  https://github.com/jpommerening/midikit is the same 
>code or not as they have no readme and the last commit is 2015.
>
>I don't know as I like to use node, but: 
>https://github.com/jdachtera/node-rtpmidi
>is a bit newer.
>
>rtpmidi that shows up in alsa or jack with zeroconf support would be a 
>nice addition to Linux audio. (as would a whole pile of other things :)
>
>
>--
>Len Ovens
>www.ovenwerks.net
>_______________________________________________
>Linux-audio-dev mailing list
>Linux-audio-dev at lists.linuxaudio.org
>https://lists.linuxaudio.org/listinfo/linux-audio-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-dev/attachments/20180829/6dc91509/attachment.html>


More information about the Linux-audio-dev mailing list