2 Sep
2018
2 Sep
'18
11:42 a.m.
On 9/2/18 4:07 AM, Len Ovens wrote:
On Sat, 1 Sep 2018, Jonathan E. Brickman wrote:
Yet another idea:
Instead of implementing RTP-MIDI (and its hacky journal), I've had a very good
experience with translating (stateless) MIDI to a (stateful) protocol for UDP
communication.
TUIO [1] builds on top of OSC and has been designed to gracefully recover from
packet loss. Don't be intimidated by the spec, you'll only need a really minimal
subset of it (easily implementable) to accomplish your goal.
[1] https://www.tuio.org/?tuio20
In general I too am attracted to UDP -- but for
MIDI performance transmission,
0.001% loss is still far too much, because that means one note in 1,000 might be
held and never released, causing massive encruditation to the moment :-) This is
because every time I press a key there's a MIDI signal for the press, and a
separate one for the release, and if the release is lost, we can have massive
unpleasantry. And a song can easily have thousands of notes. Some of my tests
over the years actually included this behavior!
All note offs must be received for good performance. I agree.
I have read a lot about OSC. It has seemed to me
that it would have to be an
option, given that it seems to have been designed from the beginning to run over
IP, and otherwise to sidestep all of the well-known MIDI limitations. But
whenever I have dug into it in the past, I have found myself quite profoundly
confused by the massive flexibility. Recently I ran into OSC2MIDI, and if my
OSC has no "standard" for performance transmition except MIDI via OSC which
ends
up having all the same problems as MIDI alone. It would of course be possible to
send messages that were note with length... but that would mean a delay at least
as long as the note was played because the message can not be sent untill note off.
understanding
of what OSC is is correct, OSC2MIDI should theoretically be able to
do the job if it is on both ends of the stream, correct? I'll do a bit of testing
of this, see if I can figure out a bit of toolchain design, but input of
experienced persons is much desired.
I personally don't see how that would help. It sounds like translating an
english email to french to send it and then translating back to english on the
receiving end. It is UDP in both cases. Unless I am missing something.
I will also look at the repos for MIDI over RTP.
Sounds like it's being used in
production now for loss-tolerant control surfaces though, and not performance
transmission, correct?
It is designed for performance as well or even first. It is a journelled setup
that sends both the performance and a journel. The journel allows missing
packets to be noted and replaced. It tries to be smart about what it recreates.
For example, a note off is always recreated even if it ends up late. A note on
that shows up after it's note off will not. So it is the better than tcp, where
a note may sound obviously out of time due to a retry. rtpmidi is what apple
coreaudio uses as it's midi transport. A properly "advertised" rtmidi port
will
show up in core audio just like any other midi port. It is however, true that
some of the linux implementations have gotten it working but have never
completed the journeling part of things (maybe because it worked for them well
enough without) and so for them it is no better than ipmidi (which also tends to
be quite good in a local network context). The transport part of the code is the
easiest and the journel part would take work... at least that is my guess as the
reason so many are partly done.
Tcp with timing information and post analysis could do the same thing, deciding
not to use late note on events. With the speed of networks inceasing and faster
processing at both ends, tcp may be fast enough. A lot depends on how busy the
network is... what other traffic is present. I have had both good and bad
exeriences with udp both on wifi and localhost. Even using localhost, it seems
too many udp packets at a time seems to result in packet loss. (I say packet
loss, but it is possible the receiving OSC lib ran out of buffer too).