2 Sep
2018
2 Sep
'18
1:49 a.m.
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(a)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(a)ovenwerks.net:
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at ponderworthy.com -- CDs and MP3 available!
Music of compassion; fire, and life!!!
On Wed, 29 Aug 2018, christoph.kuhr(a)web.de
wrote:
_______________________________________________Linux-audio-dev
mailing listLinux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev 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(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev