[LAD] OSC

[Len Ovens]

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