On Mon, 16 Feb 2015, Rick Green wrote: 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