On 09-09, Christopher Arndt wrote: I don't have much time to contribute at this point, though it would be great to know that some effort is being put into at least maintaining the existing information on the standard as well as what implementation are available for applications to use. --Mark

On Sun, 9 Sep 2018, Christopher Arndt wrote: 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. 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. 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