[linux-audio-dev] Re: [Jackit-devel] Announce - jack.clock - Linux-audio-dev

21 Jan 2004

On Wed, Jan 21, 2004 at 01:06:03 +1100, Rohan Drape wrote:
...
   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. 
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