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... 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 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