Open Sound Control (OSC) has come a long way since we introduced it
in 1997, and we hope and expect to see it keep growing in terms of
number of implementations, completeness of implementations, number of
open source implementations, ease of use, number of users, quantity
and quality of documentation, successful scientific and artistic
projects, and new application areas. The proposed additions to the
standard presented at this conference will add important new features
to the protocol. A better understanding of current technology for
server discovery and session management could lead to recommended
practices that make configuration much easier for users. Better and
more widespread clock synchronization implementations could finally
make OSC's time tags generally useful and widely implemented.
One feature that has always made OSC extremely open-ended and
versatile is the lack of specification of what an application's
address space should be. This has allowed people to use OSC for
things we designers never would have imagined, and to make up their
own meaningful names and organization for control structures. At the
same time, this lack of standardization among address spaces means
that there is no guaranteed compatibility among implementations of
OSC; in fact, almost all current uses of OSC involve a
general-purpose programming language for custom handling of a
specific address space. We would like to see a mechanism and culture
supporting developers to share their useful and mature OSC address
spaces with the entire community, which would in turn lead to the
idea of standardized interfaces with a choice of implementations.
Five decades of computer music have taught us that it's important to
control sound in many different ways and from many different
perspectives, from low-level sample-by-sample control to
frequency-domain views to "note"-level views to high-level musical
software agents. In many cases the most useful computer music
software simply provides an alternate (often lower-dimensional)
control interface to a more low-level sound control mechanism, e.g.,
real-time neural network control of additive synthesis parameters. We
imagine large collections of software modules with musically rich
behavior, driven by OSC messages. Some of these modules directly
output sound; others output OSC messages targeted at one or more
lower-level modules. The modules might run all on the same machine
or on a collection of networked machines. A module implementing a
standard OSC address space could be replaced by another module
implementing the same address space to add or change functionality
without breaking anything else.
Finally, we have some aspirations for the important role OSC can play
in the development of our favorite application area, which we would
like to call truly enactive musical instrumentation. Most of what
digital media and information technology has brought to music has
left out the human body. Music technology still pretty much looks
like office technology. Live interactive computer music performance
with gestural controllers other than the two traditional keyboards
remains a rarity. So our hope is that further development of OSC
will ease the burden of developing and disseminating a new generation
of computer-based instruments that afford the intimate and expressive
bodily acting-out of music.
We look forward to the future of OSC and to the next OSC conference!
