[LAU] Open Sound Control: Is it still a thing?

[Len Ovens]

On Tue, 27 Apr 2021, Jörn Nettingsmeier wrote:

> On 4/27/21 10:49 AM, worik wrote:
>
> OSC is very much a thing for audio rendering cores requiring more 
> complex semantics than MIDI can offer.

...

> DigiCo considers it relevant enough that they are implementing OSC 
> control capability of external devices on their desks:
>
> https://digico.biz/digico-opens-up-the-sd-range-with-generic-osc-control/

This caught my eye... hoping that "generic OSC" might be some standard for 
what controls should be called. But no. The biggest strength of OSC is 
that it can do anything... but that is also it's biggest weakness. There 
are many control applications that could benefit from standardized 
messages but every DAW and controller requires setting up a control map to 
fit the two together.

> As do LAWO and Avid, apparently.
>
> Behringer mixers have been mentioned, but the extent to which it is 
> implemented is quite amazing, to the point where one of these is nice as 
> a studio hub even if you're not actually routing audio through it :o)
>
> https://mediadl.musictribe.com/download/software/behringer/WING/BE-P0BV2-WING-OSC_Documentation.pdf

Cool, this is much better than OSC for the X32 mixers. The OSC for X32 
mixers pointed out some of the short comings of OSC over UDP:
 	- each channel had a list of parameters in each OSC
 	  message. And these parameters had no relationship to
 	  each other aside from belonging to the same channel.
 	- The meters were all grouped into one or two messages so the
 	  controller had to separate all the meter data and just know
 	  from it's possition in the parameter stream which one it was.

This of course took away most of OSC's "built in" readability.
I think this was because UDP starts to loose messages very quickly after 
100 or messages at a time. This would normally not seem like a problem but 
when you consider that any one strip (I prefer strip to channel) may have 
over 100 parameters that may be transfered at once in the case of banking 
or a scene change. Some thing I have fought with on OSC control for 
Ardour. I have had to add a very small delay with each message to make 
things work.

The Wing with TCP would not need this... but of course some 
OSC libs do not support TCP because OSC 1.0 is UDP and OSC 1.0 never got 
past OSC 1.0 due to lack of funding. There was work started on OSC 1.1 but 
it was never formalized and the documentation has vanished from the OSC 
site. This means no bundles, no TCP, no # or ? just / and so many OSC 
controllers are OSC 1.0 only.

The Wing on the other hand is doing what I have started to do with Ardour 
(while leaving the old methods alone). /strip/number/send/number/control 
type value (ei. /strip/5/send/3/pan_azimuth f 0.75 ) Except they use 
/ch/5/fdr f .782

The Wing is also using the same query mechanisim I have started to 
implement in Ardour:

send /strip/3/fader to ardour and it will replay with
/strip/3/fader f .782
(it may also send /strip/3/gain f 0 if the feedback is set that way)
send /strip for a list of strips
send /strip/2 for a list of controls with value for that strip
etc.

The problem with /ch is that a strip if stereo has two channels and if 
MIDI has 16 channels and if a VCA has none and yet they are all handled 
the same way with similar controls. So much for using /ch as a standard.

Anyway, a standard for mixer strip controls would be very nice... and of 
course mine is the best :)

Actually, if there was a standard that made any kind of sense (or maybe 
even not), that was supported by a real physical hardware OSC controller 
or two, it would be enough to make it worth supporting.

--
Len Ovens
www.ovenwerks.net