<div dir="ltr"><div>> 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><div><br></div><div>> I am working on compiling OSC2MIDI right now, does not appear trivial, we'll see :-)</div></div><div><br></div><div>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).<br></div><div><br></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" target="_blank">http://opensoundcontrol.org/spec-1_0</a></div><div><br></div><div>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.</div><div><br></div><div>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 "<span class="gmail-pl-s">-a osc.tcp://localhost:8000<span class="gmail-pl-pds">"</span></span></div><div><span class="gmail-pl-s"><span class="gmail-pl-pds">I would like to explore using something like UDT (<a href="https://git.dorkbox.com/dorkbox/UDT">https://git.dorkbox.com/dorkbox/UDT</a>) for transmitting OSC, but that seems even less likely to receive time and attention soon as it would require using an alternative to liblo.<br></span></span></div><div><br></div><div>Best of luck,<br></div><div>_Spencer<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 1, 2018 at 4:07 PM Jonathan E. Brickman <<a href="mailto:jeb@ponderworthy.com">jeb@ponderworthy.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="text-align:left;direction:ltr;word-wrap:break-word;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" target="_blank">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, <a href="mailto:christoph.kuhr@web.de" target="_blank">christoph.kuhr@web.de</a> 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" target="_blank">len@ovenwerks.net</a>:<br><br><blockquote id="m_-2088719034537665896mail-app-auto-quote" cite="http://15355728320000011926" type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex">
<div class="m_-2088719034537665896js-helper m_-2088719034537665896js-readmsg-msg">
<div>
<div id="m_-2088719034537665896style_15355728320000011926_BODY">On Wed, 29 Aug 2018, <a href="mailto:christoph.kuhr@web.de" target="_blank">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" target="_blank">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>
</div>
</div>
</blockquote>
<pre>_______________________________________________</pre><pre>Linux-audio-dev mailing list</pre><pre><a href="mailto:Linux-audio-dev@lists.linuxaudio.org" target="_blank">Linux-audio-dev@lists.linuxaudio.org</a></pre><pre><a href="https://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">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" target="_blank">jeb@ponderworthy.com</a> (785)233-9977</font></i></div><div><i><font color="#1a5d1a">Hear us at <a href="http://ponderworthy.com" target="_blank">ponderworthy.com</a> -- CDs and MP3 available!</font></i></div><div><i><font color="#1a5d1a">Music of compassion; fire, and life!!!</font></i></div></span></div></div>
_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org" target="_blank">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="https://lists.linuxaudio.org/listinfo/linux-audio-dev" rel="noreferrer" target="_blank">https://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br>
</blockquote></div>