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

From: Spencer Jackson <ssjackson71@email-addr-hidden>
Date: Tue Sep 04 2018 - 21:23:13 EEST

> 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 am working on compiling OSC2MIDI right now, does not appear trivial,
we'll see :-)

I wrote OSC2MIDI with such a use case in mind as well, though it was not my
primary one so it's not very tested (I just wanted to use android devices
to control linux synths via osc->midi). I'm happy to help you through
compiling it, I hoped that it was trivial. Please let me know whatever
issues you come across (perhaps in a github issue so we don't create too
much noise in this list).

> 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

That is a great idea, but unfortunately I have many more ideas than time of
late, so any implementation soon is quite unlikely. I would be happy to
assist/advise anyone interested in contributing this though.

On UPD/TCP IIRC liblo the OSC library I used, offers support for TCP
connections as well as UDP, and I believe all you need to do is supply an
argument like "-a osc.tcp://localhost:8000"
I would like to explore using something like UDT (
https://git.dorkbox.com/dorkbox/UDT) for transmitting OSC, but that seems
even less likely to receive time and attention soon as it would require
using an alternative to liblo.

Best of luck,
_Spencer

On Sat, Sep 1, 2018 at 4:07 PM Jonathan E. Brickman <jeb@email-addr-hidden>
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!
>
> 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@email-addr-hidden 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@email-addr-hidden:
>
> On Wed, 29 Aug 2018, christoph.kuhr@email-addr-hidden 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@email-addr-hidden
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
> _______________________________________________
>
> Linux-audio-dev mailing list
>
> Linux-audio-dev@email-addr-hidden
>
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
> --
>
> *Jonathan E. Brickman jeb@email-addr-hidden
> <jeb@email-addr-hidden> (785)233-9977*
> *Hear us at ponderworthy.com <http://ponderworthy.com> -- CDs and MP3
> available!*
> *Music of compassion; fire, and life!!!*
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Sep 5 00:15:02 2018

This archive was generated by hypermail 2.1.8 : Wed Sep 05 2018 - 00:15:02 EEST