[LAU] Replacing/enhancing MIDI, and OSC

[Len Ovens]

On Mon, 16 Feb 2015, Rick Green wrote:

> On Mon, 16 Feb 2015, Len Ovens wrote:
>
>> I think OSC is missing parts though (just like AES67?). I should be able to 
>> add a control surface/keyboard to a network and the unit should show me 
>> every other unit (SW or HW) that it can talk to. From that list I should be 
>> able to connect my output to a number of inputs and connect my input to 
>> whatever output. Then if I play notes on a keyboard I should get the right 
>> sounds, or move a control the right thing should change. That is a lot of 
>> things to happen. My controller has to be able to set it's networking up 
>> and then discover what other OSC stuff is around. OSC right now seems to be 
>> totally manual. The user has to know the target IP and port (99% musicians 
>> just blanked out) and have the server running and enter those things just 
>> to have a connection. Even with a standard set of commands this is already 
>> a fail.
>>
>  Sorry for the off-list reply, but the list server is rejecting my posts 
> today.  It seems that my buddy who hosts the aapsc.com domain for me has 
> gotten himself dropped into a dnsrbl hole...
>
>  I think you're on the right track here.  MIDI isn't extensible.  OSC is too 
> open.  It looks like XML to me - very wordy with all the 'label=value' pairs, 
> and ASCII to boot.  The extra bandwidth of ethernet is eaten up by the 
> wordiness of the command structure, so you don't really gain any 
> commands/second advantage over MIDI.
>  WHat if we had a protocol more like SNMP: Generalized like OSC, but with a 
> MIB or DTD-like dictionary delivered once at initialization by the controlled 
> device.  The controller could use this to configure itself for the 
> application, and then the actual datastream would be in a compact binary 
> 'bytecode' more like MIDI.  Best of both worlds?

considering the variety of uses for a control protocol, I think there is 
room for more than one. There are varying amounts of acceptable latency. 
What is low latency for audio, Synth control, lighting control, video, DAW 
control, are all different. MIDI for synth control is well known and the 
biggest thing it needs is a faster transport... Can't beat Jack for this. 
It will be interesting to see the new HD MIDI to see if it is a help or 
hinderance and how well supported it gets. If it allows standard MIDI 
transport over IP, that alone may make it worth while, just because it 
would give us a standard way of doing MIDI over net. However, from reading 
the blurbs on HD, it seems they have gone beyond one step up. More 
channels yes... merely changing 8 bit to 16 would go from 16 channels to 
256, but they are talking "thousands". This would indicate to me that they 
are increasing the bit width by 4x. A 16 bit word would be used just for 
channel, another just for velocity, another for release velocity, another 
for presure, another for tuning of the note (can change on a pre note hit 
basis... maybe during the note hold too... not to mention the note 
itself... SOunds like 12 bytes per key press already (by my guess). Not 
exactly compact, but perhaps more so than some OSC.

One thing to remember though, Ethernet does have minimum packet size. (42 
bytes or so as happens... minus a few more for udp/ip headers) So a single 
note on in MIDI would take the same ethernet traffic as an OSC message in 
many cases. OSC does have a sort of running status where a PWD can be set 
and can also use wild cards to send the same message to a number of 
different addresses. There is an OSC standard set of performance (note 
on/off/whatever/etc.) in the works as well that seems to be very close to 
what HD MIDI is doing. The reality is that GB ethernet is what makes 
lowlatency audio/midi possible or at least stable, not because it is 
designed for low latency work, but because it is fast enough that a small 
packet has a low latency... and on GB, MTU1500 is small packets. 100M 
networks can, if they are real quiet, do very well too. But to be reliable 
one has to design for at least moderately busy networks.

OSC does have (or can) self documenting signals. The path name tells the 
intended destination program, channel (by name or number), what is to be 
controled, and how much... all in english (or greek or whatever). The 
language could even be possibly multi-lingual without changing bandwidth.

OSC has a query setup so the sending client can find out what commands are 
available and what they do... I have more to read on this part  :)

Using ethernet as a transport for anything has to assume that the 
transport is not locked to our use. This is new to the audio/music world 
which is used to having it's own MIDI line and it's own audio port/card. 
Sharing resources has been something we have tried to avoid for years and 
now with networking, sharing has to be assumed... sort of like plugging 
one's USB audio into a hub that also has a USB drive, mouse, keyboard and 
wireless dongle using it. Fun stuff, and really not that different than 
sharing a PCI bus.

--
Len Ovens
www.ovenwerks.net