2 Sep
2018
2 Sep
'18
6:07 a.m.
On Sat, 1 Sep 2018, Jonathan E. Brickman wrote:
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).
--
Len Ovens
www.ovenwerks.net