Re: [LAD] OSC

On Sun, 9 Sep 2018, Christopher Arndt wrote:

> From the LAU list:
>
> Am 08.09.18 um 17:23 schrieb Len Ovens:
>> I would be willing to help with a govering body if there are others so
>> inclined.
>
> I'd definitely be interested in helping OSC staying relevant.
>
> I've dabled with different OSC-to-X bridges in the past. [1] [2] [3]. My
> main interest is controlling applications, which talk to some MIDI
> device, running on a desktop or Raspi or similar, from another
> application on an Android device, since MIDI and USB-OTG support on
> Android devices is still somewhat a matter of luck.
>
> The protocols I've seen so far, which embed MIDI in OSC are often too
> simplistic. If I can't transmit Sysex, for example, it's no use to me.

I agree sysex is important, as are rpn nrpn which probably can be
transmitted as four events with current protocols, but should be treated
as one osc event.

> And what is the advantage of the verbose commands MidiOSC/midioscar use
> over just using the MIDI data type OSC provides?

It would allow a midi keyboard to perform using a synth designed for OSC
performance control. That is, while in the OSC domain, the performance
would have compatablitiy with a wide range SW. This does not help someone
using OSC as a transport bridge at all and so maybe having two ways of
dealing with this problem would make sense or at least the availablility
of a raw method.

> Also, the MIDI specification has had a few additions in the past years
> and a OSC-MIDI protocol hould make sure to support those as well.

There are appendages to the MIDI 1.0 spec. Supporting them is fine, but in
a raw midi sense they mostly seem to take midi 1.0 events and give them
new meaning which doesn't really affect data bridging so much as midi
performance to OSC performance translation.

MIDI 2.* is a whole new ball game and not really backwards compatable and
as such doesn't seem to have caught on. Lots of people still use their pre
MIDI 1.0 DX7s for example. Vintage synth use is still very common so for a
new controller to be relevant, it uses MIDI 1.0.

MIDI 2, if anything, shows a need for an intermediat OSC format that
performance data can be converted to/from with possibly midi 1.0 on one
end and midi 2 on the other.

MIDI and OSC are all about controlling an application, but control for
performance is very different from control of an application's parameters.
OSC is better for both, but in the case of controlling parameters, much
better as midi is not really designed for the ways many controllers use
it. (look at the hack job mackie control uses as a great example) It is
almost worth having a MCP_to_OSC bridge for such things.

As a note, My personal use of both MIDI and OSC has been the control of
Application parameters rather than performance control (though I have made
a HW MIDI filter to allow only drum info through many years ago). I
currently work on the OSC code for Ardour to control transport, mixer, and
session values. So if it's broken, thats my fault.

Of personal interest would be an OSC standard for mixer/transport control.
I do not have an attitude that what I use now is the best. I would be ok
with adding standard based controls to Ardour if such standards are
available. However, I do have experience working with current controllers
and their shortcoming. Of particular note in this case, most controllers
are only able to deal with one control and one or two parameters per
control and often only one type of parameter (float only is common but
at least one is string only). There does not seem to be much in the way of
one message gives all parameters for one strip for example. The exceptions
are custom sw/hw such as the X32 mixers (and some parts of Ardour as
happens).

These experiences have shown that while some of the OSC query stuff in
OSC 1.1 looks good, in practice with current controllers, it doesn't work or
even really make sense. In mixer/transport control the end result is that
both the controller and the DAW or other controled unit, send control
messages as well as act on them. (we call this feedback) So rather than
querying a value, a controller asks to start receiving feedback for a
control or set of controls. The controlled device then sends the current
value of the requested control(s) as well as any changes as they happen.

A better use for query would be to find out what controls are available.
So querying strip 1 would tell how many channels it controls and what
controls it has (fader, pan, eq, plugins, etc.). Each control could be
queried to find out about subcontrols and control limits and units.
Showing how to access each would help too. Most controllers are are not
able to deal with such things right now but if there was a standard, maybe
that would change. OCA tries to do this by the way (
http://ocaalliance.com/ ) but has no performance control at all.

--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev