21 Jan
2004
21 Jan
'04
6:20 a.m.
On Wed, Jan 21, 2004 at 01:06:03 +1100, Rohan Drape wrote:
Thanks, thats helpful. I have a number of things I'd like to use OSC for
(and I've heard plenty of other linux audio people talking about starting
to use it), but theres a few things that bug me about it:
* Libraries not great. this seems solved by using the subset you're
talking about, I think it will be fine for my applications. I dont like
reinventing the wheel, but I need threadsafeness, and implementing a
library for the subset youre talking about seems easy.
* No service discovery. This is a big deal, but can be solved /if/ we
define a service discovery service before too many more people implement
OSC support :) The current situation where people just try to pick a port
number noone else is using (AFAICT) and hope it gets telepathically
transmitted to its peers is a bit fragile. Unless theres a database of
port ranges I haven't found?
* No method query. It would be nice if there was a well-known method that
caused some metadata about the other methods to be dumped. Maybe there
is and I just haven't seen it. This could also be done in the service
discovery stage though, through advertisment.
FWIW (I have some experience of optimising URL matchers), I would produce
a 64bit (or maybe only 32bit) hash of the paths, hash up incoming paths
and do a match on that. Its pretty quick (the only extra operation is the
hash and it will be < 1000 P3 cycles to execute), and allows arbitrary
length paths.
I'm very happy to discussus a GPL'd library implementation or service
discovery, but we should probably continue on l-a-d. I should
really have posted my questions there too. I've CC'd this reply.
- Steve
Also, what OSC
library are you using? libOSC and OSC Kit seem to be
non-rentrant and a bit painful to use.
jack.clock implements only a subset of the OSC protocol, more or less
the same subset as SuperCollider [SC3], and for more or less the same
reasons. In particular it does not implement the patten matching
rules and does not implement a scheduler for incoming messages [ie. it
does not accept incoming bundles]. I will add a note to this effect
in the manual. Restricting address names to seven printing characters
makes method dispatch an eight byte equality operation. Given this
the implementation is straightforward and does not require a library
beyond a simple network/host byte order convenience set. The current
implementation is unneccesarily restritive about the type of numerical
arguments, this should be relaxed, which will require a slightly more
sophistcated infrastructure. I looked briefly at the libraries you
mention a few years ago and decided much the same thing.