I think (from what I have read of the OP setup) that this case has two things that call for reliablility.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.
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.
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.