OSC Schemas: standardized OSC Address Spaces plus their semantics

An OSC Address Space is simply the list of all the messages a server understands. The term "OSC Schema" was first introduced in a very vague way at the 2002 OSC Conference; it means both an OSC Address Space plus the semantics of all the messages, including the following:

    Expected argument type(s) for each message

    Units and allowable ranges for each parameter

    The effect of each message (with respect to some model of the behavior of the OSC server as a whole)

    If and how the effects of multiple messages interact

For example, here is a very simple OSC Address Space for a two-sine-wave additive synthesizer:


/foo/amp
/foo/freq
/bar/amp
/bar/freq
/global/amp

OSC's human-readable ASCII string parameter names allow an experienced user to try to guess the meanings and expected argument types of these messages just from the names. But a more complete documentation of the OSC Schema (for this completely made-up example) would be:


/foo and /bar are the addresses of two sinusoidal oscillators. For each oscillator, /amp specifies the amplitude, on a linear scale where 1 represents the maximum of the synth's dynamic range, and /freq specifies the frequency in Hertz. The recommended range of frequencies is from 20-20000, but any nonnegative frequency can be set, and frequencies over the 22050 Hz Nyquist limit will alias. /global/amp sets the overall amplitude level; it sets the linear amplitude of a second stage of gain control that multiples the sum of the outputs of the two oscillators.

Obviously there are elements of this example OSC Schema that could be specified more formally in a machine-readable way, e.g., the units and ranges of the individual parameters. Possible technologies we could use for this include XML and RDF (part of the "semantic web").

Also, there will always be elements of the semantics of OSC messages that will be very difficult, if not impossible, to specify in a standard machine-readable way, and so at some point we will have to resort to human-readable natural language documentation.

Andy Schmeder and Matt Wright suggested that OSC Schemas be posted (in an unspecified form) on web pages. For now we're asking developers to document their schemas informally in natural language (preferably English) as "child pages" of this book. Ideally, each child page will include not just the schema, but also the design decisions that motivated the schema, rationale for rejecting competing possibilities, and a critique of the schema in terms of how well it met the goals, unforseen problems, etc.