4 Jan
2016
4 Jan
'16
7:55 p.m.
I think (from what I have read of the OP setup) that
this case has two
things that call for reliablility.
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)
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.
I can not see how adding OSC as yet another layer with no error
checking or correction could be any better than ipmidi.
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.
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.
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.
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.
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.
I really do wonder. What about this for Linux-to-Linux MIDI:
- Processes on each end of the link connect to their respective MIDI
port devices via simple binary opens
- The processes set up two TCP connections over the LAN, two separate
TCP ports, one for each direction of data flow
- The processes set up two Zmodem connections, small block sizes, one
connection each direction, one per TCP port
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.
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!