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
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
