<html dir="ltr"><head></head><body style="text-align: left; direction: ltr; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>...am running into a bobble which I am hoping you or someone else will understand :-)</div><div><br></div><div>Have assembled the two files below, midi2tcp.py and tcp2midi.py; you may find them <a href="https://github.com/ponderworthy/midi2ip">here</a>. When run thus, in separate xterms:</div><div><br></div><div>python2 tcpmidi.py localhost:44440</div><div>python2 midi2tcp.py localhost:44440</div><div><br></div><div>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?</div></blockquote><div><br></div><div>Renamed them to 'midi2ip.py' and 'ip2midi.py' for accuracy:</div><div><br></div><div><a href="https://github.com/ponderworthy/midi2ip">https://github.com/ponderworthy/midi2ip</a></div><div><br></div><div>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.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
</blockquote><div><span><pre>-- <br></pre><div><i><font color="#1a5d1a">Jonathan E. Brickman <a href="mailto:jeb@ponderworthy.com">jeb@ponderworthy.com</a> (785)233-9977</font></i></div><div><i><font color="#1a5d1a">Hear us at ponderworthy.com -- CDs and MP3 available!</font></i></div><div><i><font color="#1a5d1a">Music of compassion; fire, and life!!!</font></i></div></span></div></body></html>