<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<blockquote
cite="mid:alpine.DEB.2.10.1601040838320.2588@scott.cbbs.org"
type="cite">I think (from what I have read of the OP setup) that
this case has two things that call for reliablility.
<br>
<br>
1) The MIDI stream is heavy. It includes the whole backing
orchestration. The use of a panic button would be very noticable.
(maybe more so than the hung note it was correcting)
<br>
<br>
2) The person controlling the playback is playing a sax over top
of it and therefore needs his hands to play that. That is he has
no way of monitoring and manually correcting things.
<br>
<br>
I can not see how adding OSC as yet another layer with no error
checking or correction could be any better than ipmidi.
<br>
</blockquote>
Agreed. A panic button, for me (a multidevice keyboardist), is
about as useful as a power button. If my architecture needs a panic
button, my architecture isn't good enough for me.<br>
<blockquote
cite="mid:alpine.DEB.2.10.1601040838320.2588@scott.cbbs.org"
type="cite">
rtpmidi with journaling looks to be the best bet on this because
there is no resend needed. The journaling info is sent if needed
or not so there is much less latency required for error
correction. Journaling does not cover all possibilities BTW, but
it is very picky about note off events. In the case of controllers
the last value is journaled rather than the whole string of
values.
<br>
</blockquote>
Of all the current code bases in this thread, which are all the ones
I have heard of thus far, indeed, rtpmidi with journaling does sound
the best to me. Anyone have, or know of a source of, the old
midistream source .deb for Ubuntu? It is reported as "no longer
available", I wonder if there was a patent / copyright issue or
something.<br>
<br>
But in truth, I don't want any risk of out-of-order, or missed,
commands in the stream. Delay is fine, only as a great indicator
that I have to abandon wireless and use my backup wired approach.
If I'm spraying notes around as fast as my fingers will go on my
88's for consecutive minutes, nothing shall be out of order, or
something has to get switched out.<br>
<br>
Which, strangely enough, brings me right back to primordial
methods. After all, even audio and video streaming over a gigabit
wired LAN depends on caching if it's going to be hifi and truly
flawless, TCP/UDP was never designed to keep packets in original
order.<br>
<br>
I really do wonder. What about this for Linux-to-Linux MIDI:<br>
<br>
- Processes on each end of the link connect to their respective MIDI
port devices via simple binary opens<br>
- The processes set up two TCP connections over the LAN, two
separate TCP ports, one for each direction of data flow<br>
- The processes set up two Zmodem connections, small block sizes,
one connection each direction, one per TCP port<br>
<br>
Anyone know why this should not be maximally reliable and
low-latency too? We don't have to worry about any of the details of
the data being transmitted; Zmodem handles what history needs there
are; either the wifi rig is good enough or not. <br>
<br>
<div class="moz-signature">-- <br>
<div style="color: #993300; font-size: 0.8em; font-style: italic;">
Jonathan E. Brickman <a class="moz-txt-link-abbreviated" href="mailto:jeb@ponderworthy.com">jeb@ponderworthy.com</a> (785)233-9977<br>
Hear us at <a href="http://ponderworthy.com">http://ponderworthy.com</a>
-- CDs and MP3 <a
href="http://ponderworthy.com/ad-astra/ad-astra.html">now
available!</a><br>
Music of compassion; fire, and life!!!
</div>
</div>
</body>
</html>