Re: [LAD] MIDI-2-TCP, TCP-2-MIDI

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
Received on Sun Sep 2 12:15:01 2018