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