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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
