Subject: Re: [linux-audio-dev] [RFC] Lite OSC API
From: rd_AT_alphalink.com.au
Date: Mon Jan 26 2004 - 10:21:47 EET
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
This archive was generated by hypermail 2b28 : Mon Jan 26 2004 - 10:23:47 EET