Discussion:
[LAD] OSC
Christopher Arndt
2018-09-09 17:32:20 UTC
Permalink
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.
And what is the advantage of the verbose commands MidiOSC/midioscar use
over just using the MIDI data type OSC provides?

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.

Chris


[1] https://github.com/SpotlightKid/osc2rtmidi
[2] https://github.com/SpotlightKid/osc2mqtt
[3] https://github.com/SpotlightKid/touchosc2midi
Mark D. McCurry
2018-09-10 23:32:52 UTC
Permalink
Post by Christopher Arndt
I'd definitely be interested in helping OSC staying relevant.
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
David Runge
2018-09-11 08:34:03 UTC
Permalink
Post by Mark D. McCurry
Post by Christopher Arndt
I'd definitely be interested in helping OSC staying relevant.
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.
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
Thomas Brand
2018-09-11 14:20:54 UTC
Permalink
Post by David Runge
Post by Mark D. McCurry
Post by Christopher Arndt
I'd definitely be interested in helping OSC staying relevant.
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.
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.
Hey, i have collected a few OSC related documents in this repository some
time ago: https://github.com/7890/osc_spec

I've rewritten the spec to be rendered with asciidoc. I've started to try
to describe the byte syntax as EBNF. I've created an OpenSoundControl
organization. I've not consequently worked more on it, it's not complete
etc.

Just in case.. should i put you both to the org?

Greetings
Thomas
Len Ovens
2018-09-12 17:27:47 UTC
Permalink
Post by Thomas Brand
Post by David Runge
Post by Christopher Arndt
I'd definitely be interested in helping OSC staying relevant.
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?).
yes.
Post by Thomas Brand
Post by David Runge
Guess it would also be nice to find out what the motivations behind
abandoning 1.1 were.
just that the project was no longer funded. I don't think it was broken
and there are projects that do use some of the 1.1 spec. it is difficult
to encourage new projects (glass controlers mostly) to support 1.1 stuff
when there is no spec to point at.
Post by Thomas Brand
Hey, i have collected a few OSC related documents in this repository some
time ago: https://github.com/7890/osc_spec
Great! This is at least somewhere to point people.

--
Len Ovens
www.ovenwerks.net
Diemo Schwarz
2018-09-12 20:55:43 UTC
Permalink
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."
Post by Thomas Brand
Post by David Runge
Post by Christopher Arndt
I'd definitely be interested in helping OSC staying relevant.
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?).
yes.
Post by Thomas Brand
Post by David Runge
Guess it would also be nice to find out what the motivations behind
abandoning 1.1 were.
just that the project was no longer funded. I don't think it was broken and
there are projects that do use some of the 1.1 spec. it is difficult to
encourage new projects (glass controlers mostly) to support 1.1 stuff when there
is no spec to point at.
Post by Thomas Brand
Hey, i have collected a few OSC related documents in this repository some
time ago: https://github.com/7890/osc_spec
Great! This is at least somewhere to point people.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev
...
...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
Len Ovens
2018-09-11 17:08:40 UTC
Permalink
Post by David Runge
Post by Mark D. McCurry
Post by Christopher Arndt
I'd definitely be interested in helping OSC staying relevant.
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.
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.
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
t***@tuxfamily.org
2018-09-11 17:18:54 UTC
Permalink
Post by Len Ovens
As no one bothered
to move these documents onto the OSC site proper, those documents were
lost when these students pages were deleted ...
https://archive.org/web/ could be of help here.

Olivier
John Hammen
2018-09-11 19:41:04 UTC
Permalink
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
Len Ovens
2018-09-12 18:35:09 UTC
Permalink
Post by Christopher Arndt
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.
Post by Christopher Arndt
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.
Post by Christopher Arndt
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
Len Ovens
2018-09-12 18:44:16 UTC
Permalink
Post by Len Ovens
that would change. OCA tries to do this by the way (
http://ocaalliance.com/ ) but has no performance control at all.
I should have added that OSC is still much easier to trouble shoot using
wireshark or similar than OCA.

--
Len Ovens
www.ovenwerks.net
Continue reading on narkive:
Loading...