On 2018-09-10 19:32:52 (-0400), Mark D. McCurry wrote: I guess a good first starting point is to contact the former maintainers and get them involved (and to notify them about the website status - maybe it needs a new home?). Guess it would also be nice to find out what the motivations behind abandoning 1.1 were. Best, David -- https://sleepmap.de

On Tue, 11 Sep 2018, David Runge wrote: The site is run by a university. They or some of their students were the original maintainers. however, it seems the funding for OSC work has been removed. The original site has been left intact but some of the links were to personal web pages of students. As no one bothered to move these documents onto the OSC site proper, those documents were lost when these students pages were deleted (when the students left the school and started working?). So lost rather than abandoned may be more reasonable, though the difference is probably arguable :) I would guess the first thing would be to clone what is there so that at least that doesn't get "lost". -- Len Ovens www.ovenwerks.net

I always thought of OSC as a product of CNMAT at UC Berkeley, which is maybe doing less now with technology since the passing of its founder David Wessel: http://cnmat.berkeley.edu/event/2015/03/22/david_wessel_1942_2014 Is there not anyone on this list from CNMAT? -- Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-dev-f58952.html

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

FYI, there is also O2: https://github.com/rbdannenberg/o2 "O2 is a new communication protocol and implementation for music systems that aims to replace Open Sound Control (OSC). Many computer musicians routinely deal with problems of interconnection in local area networks, unreliable message delivery, and clock synchronization. O2 solves these problems, offering named services, automatic network address discovery, clock synchronization, and a reliable message delivery option, as well as interoperability with existing OSC libraries and applications. Aside from these new features, O2 owes much of its design to OSC and is mostly compatible with and similar to OSC. O2 addresses the problems of inter-process communication with a minimum of complexity." On 12/09/18 19:27, Len Ovens wrote: ... ...Diemo -- Diemo Schwarz, PhD -- http://diemo.concatenative.net Sound–Music–Movement Interaction Team -- http://ismm.ircam.fr IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France Phone +33-1-4478-4879 -- Fax +33-1-4478-1540