On Tue, Jul 08, 2014 at 06:48:33PM +0200, [email protected] wrote: > i would like to announce some tools around OSC. > > oschema: a format definition to describe OSC units > https://github.com/7890/oschema > > oscdoc: create HTML documentation from oschema instances > https://github.com/7890/oscdoc > > Basic idea: > -Having a standardized, machine-readable format to describe an OSC API > -Derive "stuff" from description, like documentation, code skeletons etc. > -Let programs use OSC API dynamically by looking at definition
I would certainly have to make use of the toolset in order to really gauge how well it accomplishes the goal, but IMHO that's a rather basic idea. Most of the OSC tools that have come up on my radar have run on the assumption that the API is known a priori or that it is established through some means of runtime communication. Providing a nicely serialized API specification would certainly seem to help with one of OSC's major flaws. Right now the example seems to be pretty small and it would be nicer to judge it based on a larger API. Depending on how well this system can handle enumerated paths, it might be interesting to see what an exported version of zynaddsubfx's librtosc based API might look like as interactions via a debugging curses tool have been making dynamic API queries so far (this would be a much more sizable test/stress case). (enumerated paths being /foo/bar1/ /foo/bar2/ /foo/bar100/) There was some reference to patterns, but at first glance they didn't quite look applicable. --Mark
pgphJgeQ3jU4p.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
