OpenSoundControl as defined in specification sounds like it is the way to implement simple and powerful. The problem though is that the "reference implementation" of OSC (OSCKit?) is rather a template to be modified to fit the specific application's needs rather then an easily reusable library.
Some (minor) problems with the Kit:
- it assumes that host will implement ONE transport (examples are UDP specific although i'm not sure even that's usable "out of the box")
- the code is IRIX based (simon has just modified it to compile on linux)
I suggest we use the Kit to create the following:
- a library (libOMC: Open Media Control) that's easier to reuse by custom servers and clients. The most important addition to osc is support for multiple transports (and optional implementation of some of the transports)
- a test suite of two applications:
- omc-pseudo-server :: starts up and reads the address space description from the text file. listens to requests on selected in command line transports.
- omc-shell :: connects to a server addressed in command line (adress includes transport selector and transport specific components, e.g. omc-shell UDP://localhost:6660/) and allows user enter osc requests and watch osc responses. the problem: osc is intended to be used over datagram-like transports so the interaction isn't synchronous -> the normal shell like interface won't work (the command returns immediately and response comes eventually if at all). so it will have either split screen curses interface or print-pending-responses-on-
.
example
server:
$ omc-pseudo-server -t UDP://localhost:6660/ --verbose OMC Pseudo Server v. 1.0 [UDP] waiting for packages on port 6660... [UDP] received package [OMC] parsing message: /container/subcontainer/method,10 [OMC] calling the message handler [TEST] response: /container/subcontainer/method,response ...
# on the other terminal
$ omc-shell -t UDP://localhost:6660/
Welcome to OMC Shell v. 1.0
Type in OSC messages
> /container/subcontainer/method,10{ENTER}
[SHELL] message sent
> /container/documentation{ENTER}
[PENDING RESPONSE] /container/subcontainer/method,response
[SHELL] message sent
> {ENTER}
> {ENTER}
> {ENTER}
[PENDING RESPONSE] /container/documentation,"test container"
libomc
First libomc to play with. This is just the OSC-kit adjusted to compile with linux. Include libomc.h and link against libOMC libOMC.tar.gz
libOSC++ -- Sun, 31 Oct 2004 18:28:41 +0100 reply
most people just make their own version of OSC. I'm impressed with liblo and I wrote libOSC++ and a Python implementation of OSC; libOSC++ is specifically designed to abstract away all the networking code; so does liblo. I don't think there is great value in extending the official CNMAT kit. If you do, make sure you have the newer code, which right now is hidden away behind an inaccesable URL. The tar.Z file on the CNMAT site is ancient.
ovidiorivera gelarza -- Fri, 26 Nov 2004 15:45:11 +0100 reply
tus mucica son lomegores
scheme OSC -- Sun, 26 Dec 2004 11:37:08 +0100 reply
http://www.artm.org/pub/lisp/osc/ is very early version of OSC implementation for PLT scheme (a.k.a. mzscheme). I wanted to make it other schemes compatible, but I don't have time at the moment.