3 Jan
2016
3 Jan
'16
9:28 a.m.
On 03.01.2016 03:24, Jonathan Brickman wrote:
Some may remember, I tried a full-court press on MIDI
over wifi about
eighteen months ago, using a couple of different methods; there were
occasional losses in realtime play, enough key-up commands lost that it
could not be used. So I gave it up for then and eventually found a
different use for my Rpi2.
But the prevalence of tablets as OSC+MIDI controllers, over wifi, has
not ceased to nag at me. I'm not interested in having a tablet -- my
keyboard is all I need -- but I am very interested in configuring an
RPI2 or equivalent in place of that tablet, so that I can wire keyboard
to RPI2 and then go wireless to the synth.
Now if I understand this Wikipedia article
<https://en.wikipedia.org/wiki/Open_Sound_Control> correctly, SLIP is
commonly used to encapsulate OSC signals. This could be a great clue,
because SLIP is very definitely a protocol which can give us
verification and recovery of lost signals, i.e., signals lost in the
normal wifi situation. And I have seen the Pure Data method of
converting OSC to MIDI and back, so that is not too much of a problem.
The question I have is, what would be the best method of verifying,
configuring, and debugging SLIP encapsulation? To do this well, for
production on stage, I have not not only be able to checkbox on for
SLIP, but trigger warnings if it detects a certain degree of errors.
Thoughts, anyone?
As others have pointed out already, SLIP is merely used as a means of
framing packet data (e.g. IP, OSC) on 'unreliable' streams (e.g. serial
lines). Some clients (e.g. PureData) even use it for 'reliable' streams
(e.g. TCP).
First decision you have to take is if you want to go UDP or TCP. As you
want to do live input, TCP may be too slow on wireless because of
frequent retransmissions.
Depending on what you want to do, TCP may just be good enough. Thus
simply use any of the available OSC and network MIDI libraries
(RTP-MIDI, ipMIDI, ...) in TCP mode (if the library should support it).
If you need it to be more responsive, you want to use UDP. As you have
seen, UDP packets tend to get lost on wireless. The solution is to use a
means of transport insusceptible to lost packets.
For OSC, you can use TUIO1 [1] or TUIO2 [2]. They quite elegantly
circumvent the problem of lost packets by transmitting (almost) full
state information. There are numerous implementations out there [3].
[1] http://www.tuio.org/?specification
[2] http://www.tuio.org/?tuio20
[3] http://www.tuio.org/?software
For MIDI, use RTP-MIDI [4] with enabled journaling. The RTP-MIDI journal
enables clients to recover from lost packets (the journal contains
critical state information). I am not sure whether there is a readily
available implementation of RTP-MIDI journaling for GNU/Linux, though.
[4] https://tools.ietf.org/html/rfc4695
As a workaround, it may be fun to encode MIDI to TUIO at the sender and
decode it back at the receiver...