opensoundcontrol.org

1. INTRODUCTION
Gesture sensing (controllers, augmented instruments, body gestures) requires accurate sampling and low latency, especially for the direct control of sound parameters with high-resolution control. Our design strategy is to develop an acquisition platform with high-quality digitization that can be used in several distinct configurations: from sensing the gesture of musicians to tracking the movements of several dancers. A particular implementation of this design, the EtherSense will be commercially available shortly.

As discussed in [1] we found that most commercial acquisition systems were unsatisfactory for the increasingly complex sensing technology needed for performance arts. However Network Technology offers nowadays interesting opportunities while OSC rises as a standard. At the same time, network technolgy has key features in the context of live performance, such as long cable support, fast data-rate and robustness

2. SYSTEM ARCHITECTURE
Our goal was to build a versatile system suitable for gesture research, allowing us to experiment and to prototype with various sensors systems. The main requirement was to use a hardware base comparable to a fully manufactured and ready-to-use product. Therefore, we decided to separate the Ethernet and OSC functions from a set of various application modules, including for example wireless receptors, digitizers, digital-to-analog converters and relays. We thus opted for a Mother Board (Ethernet & OSC) / Daughter Board (DB) architecture as described by figure 1.

A simple Q&A protocol layer allows for the communication between the mother and the daughter boards. These latter ones can be for example multiple channel digitizers, DACs, PWM servo controllers or a custom mix of several functions (up to 16 boards can be connected on the same bus).

A DB transmits its contents on the mother’s request, with custom sampling period, which can be defined for each DB (a 1400 Hz sample rate can be achieved with a single card ON).



Figure 1 : System architecture


Digitized data is then inserted as a integer list into the OSC buffer with an OSC address related to the concerned MB and DB like /Ethersense04/DB02 [16 int. list].

Data routing and unpacking can be therefore easily achieved on the host computer. The Ethersense is composed of two 16 channel 16 bit digitizing daughter boards. External 15 pin DSub connectors allow direct sensor connection and export power supply while a D-Sub to ¼” jack pig tail connector make sensor experiments easy.

3. WIRELESS PROTOTYPES
Dance performances need wireless portable equipment. The main challenge is to allow several performers to be equiped with sensors while FCC regulations make large spectrum radio frequency broadcast difficult.

WiFi was the next logical step for experimenting high-speed wireless network solutions. WiFi adapters are now embedded in most laptops or can be added to a computer. Note that 802.11 is not Ethernet per se, it is a wireless hardware and protocol standard. However, it has been designed to transport Ethernet: sending OSC through WiFi is straightforward. WiFi has also features 13 channels with 5 non-overlapping ones. Current experiments showed that 5 digitizing terminal could share the same channel at a 5ms transmission rate. Still at experimental stage, we have successfully tested the unit with dancers equipped with accelerometers and flexion sensors.

5. CONCLUSIONS AND FUTURE WORK
The general performance of the acquisition system architecture is excellent. Overall these developments are very promising.

We have designed custom DBs that can be connected to our OSC board, such as two measurement cards for an augmented violin with accelerometers.

The WiFi prototype now has an embedded LCD and an autonomy of 1h35 with alkaline AAA batteries. Rechargeable ones can be also used and an external AA battery pack might extend the autonomy to 3 or 4 hours.

6. REFERENCES
[1] Fléty, E. & al. “Versatile sensor acquisition system
utilizing Network Technology” Proceedings of NIME, NIME 2004 – Hamamatsu – SUAC – Japan.

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!