4 Sep
2018
4 Sep
'18
3:08 p.m.
...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(a)ponderworthy.com (785)233-9977
Hear us at ponderworthy.com -- CDs and MP3 available!
Music of compassion; fire, and life!!!