[linux-audio-dev] [RFC] Lite OSC API

[rd at alphalink.com.au]

I am afraid have gotten to your OSC messages a bit late, I can only 
read lists at web archives at present and the jack lists have been
down...

> * No service discovery. This is a big deal, but can be solved /if/ we

I don't know of a database, which I guess is not a good situation.
CNMAT might be interested in doing the basic administration required
for a port register.  I think that a database of static port numbers
is preferable to a dynamic system *if* it is workable.  If a dynamic
system were neccessary it should be implemented as an OSC server!  I
am actually not exactly sure what you mean by service discovery?

> I'm very happy to discussus a GPL'd library implementation or

I have had to do some work on the OSC implementation I have been 
using
in order to address two issues.  I think you will need to address
these with liblo also.  They are: 1. type coercion and 2. variable
argmument messages.  

I am going to attach the note I wrote about the implementation below,
which describes these in detail, but briefly on type coercion:

Given the message shape ("/foo/bar" "fi") as in the testlo.c file, a
receiver should match not only ("/foo/bar" "fi" 2.0 23) but also
("/foo/bar" "ii" 2 23) and ("/foo/bar" "if" 2 23.0) and in fact all
other possible numerical encodings, and provide them to the handler in
the form requested.

The work I have done *only* provides the byte string decoder and
encoder, but it does support all the extended basic OSC types and
numerical and string coercion.  I think you could use it as is if you
wanted, or of course just take whatever you need.  I will happily
implement/apply any changes/fixes required to make it usable for you.
The implementation is in the file 'osc.c' in the jack.clock or
jack.scope archives at <http://www.alphalink.com.au/~rd>.  It
works for me but is otherwise untested!

Apart from the above the design looks good, although personally I
agree with James McCartney, see SC3 or recent post to OSC_dev, that
combining the verb and the subject in the address is a bad idea, and
would prefer to see a library that discourages that use ;) (This would
also make the handler type declarations simpler...)

Regards,
Rohan

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: osc.text
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20040126/9492a9b8/attachment.text>