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
