I have set up and run a number of tests now. Mido under python2, uses 5-7% of two different 2.4GHz+ cores for a one-way midi2tcp --> tcp2midi link based on the sample code using blocking waits on both MIDI and TCP ports. I ran into minor difficulty getting Mido into python2, and difficulty considerably beyond my knowledge getting Mido into python3, into this up-to-date Manjaro, so my next tests were midi2udp --> udp2midi using just Python3 and libraries JACK-Client and 'socket'; this is quite promising, just 2% CPU total, and the test is a bit crude. So now I'm working on designing an algorithm which models a hardwired MIDI cable over a UDP connection. Specific goals are:

- MIDI over IP. Using UDP right now, will use TCP if a reason to do so emerges.

- Simplicity. I want this implementable in dedicated hardware as easily and inexpensively as possible. I want $20 boxes where I can dial the src/dest IPs using dip switches. Dreaming? Maybe...

- Very well-suited for live performance. This means absolutely no MIDI event dropouts without being unaware, and using MIDI resends and reset in emergency to handle packet loss.

- Solid LAN immediately. Very slightly lossy LAN/WLAN next. WAN if there is call for it.

- Reliability and predictability at MIDI standard speeds -- 31.5 kHz -- not bandwidth availability. Once this works it may be doubled or quadrupled, or brought to HD-MIDI's clock once someone decides on one.

The current software thought is to have both sides have two threads: one thread running callback to JACK, the other handling UDP/TCP, the threads communicating by Python FIFO queues, the UDP/TCP thread being constrained by 31.5kHz wait-state loop of some sort.

Any suggestions, abridgements, et cetera? Also any thoughts on the best way to build that UDP/TCP thread wait-state loop? I'm beginning to imagine that TCP might have the advantage of being able to build up the buffering...but all of this has been fairly far from my practical programming, and I know that so many of you live here, so I thought I might ask :-)

--