[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-audio-dev
Subject: Re: [LAD] MIDI-2-TCP, TCP-2-MIDI
From: "Jonathan E. Brickman" <jeb () ponderworthy ! com>
Date: 2018-09-01 21:49:48
Message-ID: 0bda1ebaed36936c1227c6c3306b1100307896a2.camel () ponderworthy ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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!
So it's either TCP only, or it's UDP with complete error
correction. UDP with complete error correction is how NFS over UDP has
been working for ages, so that is clearly an option, but it is also not
exactly trivial programmatically :-)
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 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 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?
I had not realized that TCP could produce timing errors, I do
understand that now, I remember that being a challenge in the early
development of streaming audio. I wonder if OSC2MIDI can use OSC time
tag data to handle:http://opensoundcontrol.org/spec-1_0
I am working on compiling OSC2MIDI right now, does not appear trivial,
we'll see :-)
J.E.B.
On Thu, 2018-08-30 at 08:11 +0300, christoph.kuhr@web.de wrote:
> Hey Len,
>
> thanks for the insight.
>
> I never used OSC this way so far.
>
> I also did not know that there are existing RFCs for MIDI over RTP,
> which is very nice!
>
> So, yeah, lets do that.
>
> I will take a closer look at the code repos you posted. I definitly
> want to give this a try!
>
> But I am rather busy at the moment, so don't expect too fast progress
> in this matter ;-)
>
> BR,
>
> Ck
>
> Mittwoch, 29 August 2018, 09:00nachm. +01:00 von Len Ovens
> len@ovenwerks.net:
>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, 29 Aug 2018, christoph.kuhr@web.de
> > wrote:
> >
> >
> >
> > > I would always prefer a UDP based solutions, because TCP can
> > really mess up the
> >
> > > timing. UDP packetloss usually is below 1%. The bigger problem in
> > this case are
> >
> > > WIFI connections, scrambled packet orders and jitter.
> >
> > >
> >
> > > Are there any objections to using Open Sound Control based
> > solutions?
> >
> > > To me it makes more sence, because it is an IP-based protocol (32
> > bit) in
> >
> > > contrast to MIDI, which is designed for 8 bit serial interfaces.
> >
> >
> >
> > OSC being lossless has not been my experience. The problem I have
> > had is
> >
> > the OSC messages are generally one message per packet which means
> > that a
> >
> > large group of messages can overwhelm udp quite easily. OSC does
> > allow for
> >
> > using bundles of messages to be performed at the same time, however
> > MIDI
> >
> > to OSC cannot really determine a group of events that happen at the
> > same
> >
> > time because of it's (slow) serial nature.
> >
> >
> >
> > Do note that the osc message "stormes" I have had trouble with are
> > bigger
> >
> > than what MIDI was designed to handle in realtime (10 events from
> > 10
> >
> > fingers). I am talking about refreshing a control surface with at
> > least 8
> >
> > strips with each strip having 20 or so events. So well over 100
> > events.
> >
> > When I tried to use bundles, I found that no control surfaces
> > created or
> >
> > understood bundled messages. I ended up adding a small delay in the
> > sends
> >
> > to fix this... not very "real time" :) Not noticable while moving
> > one
> >
> > control like a fader but noticable if performing music.
> >
> >
> >
> >
> >
> > --
> >
> > Len Ovens
> >
> > www.ovenwerks.net
> >
> >
> > _______________________________________________
> >
> > Linux-audio-dev mailing list
> >
> > Linux-audio-dev@lists.linuxaudio.org
> >
> > https://lists.linuxaudio.org/listinfo/linux-audio-dev
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> _______________________________________________Linux-audio-dev
> mailing listLinux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
--
Jonathan E. Brickman jeb@ponderworthy.com (785)233-9977
Hear us at ponderworthy.com -- CDs and MP3 available!
Music of compassion; fire, and life!!!
[Attachment #5 (text/html)]
<html dir="ltr"><head></head><body style="text-align: left; direction: ltr; \
word-wrap: break-word; -webkit-nbsp-mode: space; line-break: \
after-white-space;"><div>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! \
</div><div><br></div><div>So it's either TCP only, or it's UDP with complete \
error correction. UDP with complete error correction is how NFS over UDP has been \
working for ages, so that is clearly an option, but it is also not exactly trivial \
programmatically :-)</div><div><br></div><div>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 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.</div><div><br></div><div>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?</div><div><br></div><div>I had not realized that TCP could produce timing \
errors, I do understand that now, I remember that being a challenge in the early \
development of streaming audio. I wonder if OSC2MIDI can use OSC time tag data to \
handle:</div><div><a \
href="http://opensoundcontrol.org/spec-1_0">http://opensoundcontrol.org/spec-1_0</a></div><div><br></div><div>I \
am working on compiling OSC2MIDI right now, does not appear trivial, we'll see \
:-)</div><div><br></div><div>J.E.B.</div><div><br></div><div>On Thu, 2018-08-30 at \
08:11 +0300, christoph.kuhr@web.de wrote:</div><blockquote type="cite" \
style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p \
style="margin-top: 0px;" dir="ltr">Hey Len,</p> <p dir="ltr">thanks for the \
insight.<br> I never used OSC this way so far.</p>
<p dir="ltr">I also did not know that there are existing RFCs for MIDI over RTP, \
which is very nice!</p> <p dir="ltr">So, yeah, lets do that.<br>
I will take a closer look at the code repos you posted. I definitly want to \
give this a try!<br> But I am rather busy at the moment, so don't expect too fast \
progress in this matter ;-)</p> <p dir="ltr">BR,<br>
Ck</p>
Mittwoch, 29 August 2018, 09:00nachm. +01:00 von Len Ovens <a \
href="mailto:len@ovenwerks.net">len@ovenwerks.net</a>:<br><br><blockquote \
id="mail-app-auto-quote" cite="15355728320000011926" type="cite" style="margin:0 0 0 \
.8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div class="js-helper js-readmsg-msg">
<style type="text/css"></style>
<div>
<base target="_self" href="https://e-aj.my.com/">
<div id="style_15355728320000011926_BODY">On Wed, 29 Aug 2018, <a \
href="mailto:christoph.kuhr@web.de">christoph.kuhr@web.de</a> wrote:<br> <br>
> I would always prefer a UDP based solutions, because TCP can really mess \
up the<br> > timing. UDP packetloss usually is below 1%. The bigger problem in \
this case are<br> > WIFI connections, scrambled packet orders and jitter.<br>
> <br>
> Are there any objections to using Open Sound Control based solutions?<br>
> To me it makes more sence, because it is an IP-based protocol (32 bit) in<br>
> contrast to MIDI, which is designed for 8 bit serial interfaces.<br>
<br>
OSC being lossless has not been my experience. The problem I have had is <br>
the OSC messages are generally one message per packet which means that a <br>
large group of messages can overwhelm udp quite easily. OSC does allow for <br>
using bundles of messages to be performed at the same time, however MIDI <br>
to OSC cannot really determine a group of events that happen at the same <br>
time because of it's (slow) serial nature.<br>
<br>
Do note that the osc message "stormes" I have had trouble with are bigger <br>
than what MIDI was designed to handle in realtime (10 events from 10 <br>
fingers). I am talking about refreshing a control surface with at least 8 <br>
strips with each strip having 20 or so events. So well over 100 events. <br>
When I tried to use bundles, I found that no control surfaces created or <br>
understood bundled messages. I ended up adding a small delay in the sends <br>
to fix this... not very "real time" :) Not noticable while moving one <br>
control like a fader but noticable if performing music.<br>
<br>
<br>
--<br>
Len Ovens<br>
<a href="http://www.ovenwerks.net" target="_blank">www.ovenwerks.net</a><br>
</div>
<div>_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="https://lists.linuxaudio.org/listinfo/linux-audio-dev" \
target="_blank">https://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br> </div>
<base target="_self" href="https://e-aj.my.com/">
</div>
</div>
</blockquote>
<pre>_______________________________________________</pre><pre>Linux-audio-dev \
mailing list</pre><pre><a \
href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a></pre><pre><a \
href="https://lists.linuxaudio.org/listinfo/linux-audio-dev">https://lists.linuxaudio. \
org/listinfo/linux-audio-dev</a></pre><pre><br></pre></blockquote><div><span><pre>-- \
<br></pre><div><i><font color="#1a5d1a">Jonathan E. Brickman <a \
href="mailto:jeb@ponderworthy.com">jeb@ponderworthy.com</a> (785)233-9977</font></i></div><div><i><font \
color="#1a5d1a">Hear us at ponderworthy.com -- CDs and MP3 \
available!</font></i></div><div><i><font color="#1a5d1a">Music of compassion; fire, \
and life!!!</font></i></div></span></div></body></html>
[Attachment #6 (text/plain)]
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic