[LAU] Berlin Linux Audio meeting @ c-base 2018-09-11

[Len Ovens]

On Sat, 8 Sep 2018, David Runge wrote:

> On 2018-09-05 14:40:19 (+0200), Daniel Swärd wrote:
>> - Start defining a standard for communicating midi messages via OSC.
> Hmmmmmm, aren't there some projects doing this already (somehow)? Has
> someone gathered background info on that?

OSC really needs a governing body. The OSC home page is pretty much a 
mess. The OSC 1.1 spec was not only not finalized but is now "Page not 
found". There is (was?) at least a proposal for midi over osc however all 
the links on 
http://opensoundcontrol.org/wrapping-other-protocols-inside-osc are dead.
There are applications/utilities that do midi/osc conversions which means 
there is at least one (probably more) protocol out there. However, 
creating a standard is not useful in the slightest if there is no 
governing body to give an approval stamp.

These two projects use the same syntax:
https://github.com/jstutters/MidiOSC
https://github.com/rrbone/midioscar

Also look at things like:
https://github.com/fabb/SynOSCopy/wiki
Which is an OSC only synth protocol (not a standard really). It should 
really be a super set of what midi is. That is, it contains the 
information that midi does but also more and with greater accuracy. Being 
able to convert from here to midi and back may make sense... with some 
exceptions. The exceptions are all applications that use midi for things 
it is not designed for... like controling mixers for example where a note 
on is used as mute and several channels of pitch are used as faders. Such 
cases would be better off with /midi/event_type/channel params style of 
things so the events are exact in and out.

Should a governing body get set up and OSC move forward, I would like to 
see that bundles are handled by the osc libs out there... that is bundle 
arrives, lib presents bundle's messages to application as single messages 
all with the same time stamp unless the application tells it not to. Why? 
because in most cases, even if the lib has methods for dealing with 
bundles, the application developer ignores them and udp is easy to over 
run with lots of small packets. I would note that many application 
developers only allow one parameter per message as well. Those that do 
allow more than one parameter expect all parameters to apply to one knob 
or switch (or note).

OSC's greatest plus is that it is incredibly flexible... this seems to be 
it's greatest downfall as well. OSC 1.0 is all there is, until someone is 
willing to take over the website and goverance, OSC is stuck there and can 
not move on.

I am sorry, but I will not be able to attend... unless someone sends me 
plane tickets :)

I would be willing to help with a govering body if there are others so 
inclined.

--
Len Ovens
www.ovenwerks.net