4 Jan
2016
4 Jan
'16
7:36 p.m.
On Mon, 4 Jan 2016 09:07:17 -0800 (PST)
Len Ovens <len(a)ovenwerks.net> wrote:
On Mon, 4 Jan 2016, Christopher Arndt wrote:
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.
Am 04.01.2016 um 00:30 schrieb Len Ovens:
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 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.