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

From: Jonathan E. Brickman <jeb@email-addr-hidden>
Date: Tue Sep 04 2018 - 13:59:56 EEST

> ...am running into a bobble which I am hoping you or someone else
> will understand :-)
>
> Have assembled the two files below, midi2tcp.py and tcp2midi.py; you
> may find them here. When run thus, in separate xterms:
>
> python2 tcpmidi.py localhost:44440
> python2 midi2tcp.py localhost:44440
>
> the second connects with the first via TCP, and they both sit
> quietly, waiting. In Catia, I connect RtMidiIn-Client to UM-ONE (USB
> MIDI interface to my keyboard), everything still sits quietly. Then
> I press one key on the keyboard once, and both sides report note_on
> and note_off over and over again, without stopping until I terminate
> them! Have gone over the Mido docs and sample code several times,
> have tried setting 'message' to None after transmit and after receive
> on both sides, have also recoded to use accept(), no change. Have
> not found a way to handle this besides terminating and restarting the
> TCP connection at every message. Ideas anyone?

Renamed them to 'midi2ip.py' and 'ip2midi.py' for accuracy:
https://github.com/ponderworthy/midi2ip
Once the current odd behavior is resolved, I had a next step in a
dream: the very simplest method to ensure serial behavior is probably
something from the very old modem days, where everything one typed was
echoed back from the receiver for verification. At the extremely low
(modernly) bandwidth of MIDI this is more than practical, and it
ensures sufficient reliability: if the sender does not get its
identical acknowledgement in perhaps 50ms, it sends probably a SysEx
representing 'retry', waits for the retry confirmation, tries that two
more times, and then tries three times to do a clean MIDI reset, and
then three times to do a MIDI panic. Or something like that, need to
incorporate socket checking in there too. But as simple as possible,
let's make the future stage hardware as inexpensive as we can :-) 50ms
is very large, but intentionally so, this is detection of failure not
jitter, it means the setup will still work with major jitter in some
marginal circumstances. When circumstances get worse, we might want to
look at running this over SSH or some such.

-- 
Jonathan E. Brickman   jeb@email-addr-hidden    (785)233-9977
Hear us at ponderworthy.com -- CDs and MP3 available!
Music of compassion; fire, and life!!!

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Sep 4 16:15:01 2018

This archive was generated by hypermail 2.1.8 : Tue Sep 04 2018 - 16:15:01 EEST