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@ponderworthy.com   (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
Music of compassion; fire, and life!!!