Re: [LAD] OSC Practices

On 06/02/2010 12:51 AM, Paul Davis wrote:
> On Tue, Jun 1, 2010 at 4:01 PM, Olivier Guilyardi <list@email-addr-hidden> wrote:
>
>> 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.

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.

> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev