2 Jun
2010
2 Jun
'10
1:04 p.m.
On 06/02/2010 12:51 AM, Paul Davis wrote:
On Tue, Jun 1, 2010 at 4:01 PM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
This relates to I was just thinking about before reading your mail. I was
telling myself that OSC is a bit like XML, which is a meta-language, thus a
specification that allows to write languages. For example, RSS can be considered
a such language.
Whereas OSC just looks like a generic RPC
mechanism, thus requiring some
development knowledge or custom-made tools.
this is exactly correct.
there is no established way to send an OSC message to an arbitrary
receiver and reliably accomplish anything at all. there is no standard
message set to ask the receiver to play a note, stop playing a note.
ditto for transport control, and just about everything else you could
imagine. in short there are no standards.
the only thing that does exist is a "meta-standard" to query the OSC
namespace, and arguably another meta-standard to get the current value
of any readable target within the namespace. as you have surmized, in its current state OSC cannot
possibly be
considered as a replacement for MIDI as a generic communication
protocol for musical-related tasks. what it does to is to provide a
common transport mechanism and a standard namespace convention (the
lowly '/'), and the agreement to use text messages which makes adding
certain capabilities to a pair of receivers and transmitters just a
bit simpler than it otherwise would be.
Well, maybe that it's not OSC that must evolve, just as XML is fine where it
stands. But there could be a higher-level specification, (as RSS in my example),
which programs and devices could choose to follow.
I'm thinking about some quite open standard. Not something which is very strict,
but certain rules, or better said recommendations, which try to bring some
coherence into the OSC (audio) world. Some very simple primitives could be:
1. in/out symmetry, eg: send and receive from/to /path/volume %f
2. put "coordinates", such as track index in the path, not as a value
3. always use zero (or one, whatever) based indexes
4. maybe some range specification for level controls
5. some recommendation for encoding notes
6. etc...
Anyway, before a such specification/standard exists, I suppose I have to look
around, and draw my own conclusions..
Therefore, it's currently a matter of "practices".. So, if anyone who has a
good
knowledge of these can shred some light on the specific issues that I mention,
I'll be glad to read about it.
--
Olivier