Len Ovens len at ovenwerks.net
Sun Sep 2 04:07:21 CEST 2018

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

More information about the Linux-audio-dev mailing list