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

[Steve Harris]

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