On 9/2/18 4:07 AM, Len Ovens wrote: > 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.
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 >> 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). _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
