On Mon, 4 Jan 2016 09:07:17 -0800 (PST) Len Ovens <len@xxxxxxxxxxxxx> wrote: > On Mon, 4 Jan 2016, Christopher Arndt wrote: > > > Am 04.01.2016 um 00:30 schrieb Len Ovens: > >> MIDI, unlike audio, must have 100% reliablility to be useful. > > > > Despite all the theorizing about which network protocol works best for > > MIDI, the TouchOSC appp for iOS/Android just sends MIDI messages as OSC > > via UDP [1] and in practice, this works very well and reliable in my > > home wifi network, even with encryption. > > > > I use this without problems to control soft synths loaded into Carla via > > my iPad using the the software touchosc2midi [2]. Works very well for > > parameter control via control change messages, but the latency is even > > low enough to be able to play notes on the tablet, if the timing doesn't > > need to be too accurate. I haven't had any dropped messages yet. > > 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. > > 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. > > I think any of these protocols are event based so that > the likelyhood of partial events showing up is minimized. I am not sure > how sysex events longer than packet size are handled, but it would be > simple enough to add sequence numbering and not start forwarding a sysex > till the whole thing reaches the receiving end. So really it is only > performance data where one event completes another that is at issue. > > -- > Len Ovens > www.ovenwerks.net One of the things very much to our advantage is that the MIDI hardware runs at a snails pace compared to all the likely communication systems. Even with (usually not critical) single byte running status, that's an absolute maximum of 3kHz. Some years ago I was involved in a networked project for a large industrial plant that had similar speed differential and high reliability requirement (24,358) our guys decided to go for fixed size checksummed packets, and the network master would keep sending the same packet until either it got a valid reply or the allotted time slot had expired. In that case the latter would sound an alarm and attempt to set the faulty unit into a failsafe mode. For a MIDI protocol I would imagine the failsafe would be for the receiving end to apply an all notes off for just the non-responding channel, and for both ends to attempt some form of silent comms reset. I would agree with Len that sysex should only be acted upon once a fully verified set of packets had been received. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
