Dynamic Interactivity Inside the AlloSphere

Charles Roberts, Matthew Wright, JoAnn Kuchera-Morin, Lance Putnam,Graham Wakefield

AlloSphere Research Group and Media Arts & Technology ProgramUniversity of California, Santa Barbara

{c.roberts, matt, jkm, l.putnam, wakefield}@mat.ucsb.edu

ABSTRACTWe present the Device Server, a framework and applica-tion driving interaction in the AlloSphere virtual realityenvironment. The motivation and development of the De-vice Server stems from the practical concerns of managingmulti-user interactivity with a variety of physical devicesfor disparate performance and virtual reality environmentshoused in the same physical location.

The interface of the Device Server allows users to seehow devices are assigned to application functionalities, al-ter these assignments and save them into configuration filesfor later use. Configurations defining how applications usedevices can be changed on the fly without recompiling orrelaunching applications. Multiple applications can be con-nected to the Device Server concurrently.

The Device Server provides several conveniences for per-formance environments. It can process control data ef-ficiently using Just-In-Time compiled Lua expressions; indoing so it frees processing cycles on audio and video ren-dering computers. All control signals entering the DeviceServer can be recorded, saved, and played back allowingperformances based on control data to be recreated in theirentirety. The Device Server attempts to homogenize the ap-pearance of different control signals to applications so thatusers can assign any interface element they choose to appli-cation functionalities and easily experiment with differentcontrol configurations.

KeywordsAlloSphere, mapping, performance, HCI, interactivity, Vir-tual Reality, OSC, multi-user, network

1. INTRODUCTION

1.1 MotivationsThe Device Server provides tools and methodologies for

manipulating control data dynamically and flexibly. It cur-rently drives interactivity inside the UCSB AlloSphere, athree-story, spherical, immersive environment dedicated toartistic performance and scientific research [2]. Applicationsdeployed in the AlloSphere range from algorithmic musicand visualization engines to simulations of sub-atomic elec-

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.NIME2010, 15-18th June 2010 Sydney, AustraliaCopyright remains with the author(s).

tron spin in hydrogen atoms. The Device Server’s designstems from the practical concerns of managing interactivityin this wide variety of virtual environments; we believe ithas reached a level of maturity and generality where it maybe broadly useful in the NIME community.

The initial design for the Device Server addressed thefollowing primary concerns:

• A physical space the size of the AlloSphere (approxi-mately 715 m3) requires multiple computers to driveactive stereo visualizations and spatialized sonifica-tions. A centralized hub for interactivity can dis-tribute control data to these computers concurrently.

• Enable users to easily customize how they interactwith applications.

• Free application developers from worrying about de-vice drivers or any other implementation details ofinteractive devices, allowing them to focus on expos-ing interactive functionality within their applications.Instead of hard-coding any device-specific knowledgeinto applications, make all applications device-agnosticand relate device affordances to application function-ality with an explicit mapping layer[10].

• Visual and sonic rendering machines should not be re-sponsible for processing control data. Let the DeviceServer efficiently handle common control data process-ing tasks such as filtering and thresholding.

• Initializing visualization and sonification engines whenswitching from one virtual environment to another canbe a complex task. A typical AlloSphere demonstra-tion involves experiencing five or six virtual environ-ments on different hardware and software platformsin half an hour; moving between these environmentsmust be as smooth as possible and avoid delays andtechnical glitches. Use of the Device Server should au-tomate changing interactive configurations so that nohuman intervention is required.

• Provide a centralized console for monitoring all controldata and troubleshooting all connections.

1.2 TerminologyA Device is a piece of hardware or software that provides

interactive affordances. A Device is often an aggregation ofControls. Example devices include Wiimotes, MIDI Key-boards and camera tracking systems.

A Control is a single interactive element that is part of aDevice. For example, a joystick on a gamepad Device hasone Control for the X direction and a second Control forthe Y direction.

A Mapping links an application functionality to a partic-ular Control on a particular Device, with an optional Lua

Proceedings of the 2010 Conference on New Interfaces for Musical Expression (NIME 2010), Sydney, Australia

57

programming language expression that is evaluated when-ever data is received from the Control assigned to the Map-ping.

1.3 Related WorkFrameworks for interactivity can generally be divided into

those geared towards use in Virtual Reality Environments(VREs) and those geared towards use in artistic expression.The Device Server is the first framework for interactivityexplicitly designed for both uses; brief descriptions of otherframeworks from both fields are provided below.1

1.3.1 Virtual Reality Interactive FrameworksThe VR community has a longer history of creating soft-

ware infrastructures for managing interactivity than thatof the digital arts community. Although many interactiveframeworks such as Vrui[4] and Gadgeteer[1] are part oflarger VR development environments the most pervasiveVR interactivity framework, the Virtual Reality PeripheralNetwork (VRPN)[8] is a standalone interaction library thathas been in development and usage for over a decade.

In addition to handling device drivers and networked com-munication, VRPN and other VR frameworks commonlyfeature abstractions that allow one device to be easily swappedwith another. In VRPN this is enabled through the useof device categories: Tracker, Button, Analog, Dial andForceDevice; the Vrui and Gadgeteer frameworks use a sim-ilar set of categories. Any tracker device can be substitutedwith any other tracker; any button with any other buttonetc. However, these abstractions require client applicationfunctionality to be built around them. An application pro-grammed to use a joystick for navigation cannot use a track-ing device instead without changing and recompiling appli-cation source code. This is in direct contrast to abstractionsfound in the Device Server which decouple application func-tionality from device-specific constraints.

1.3.2 Interactive Frameworks for Musical and Artis-tic Expression

Perhaps the most significant difference between VR in-teractivity frameworks and those intended for artistic con-texts is the use of GUIs. None of the the VR frameworksmentioned has a GUI to monitor server state or device con-nections; in contrast, many tools geared towards musicalexpression prominently feature user interfaces.

In addition to monitoring state and connections, the GUIfor the Mapping Tools of the McGill Digital Orchestra Tool-box (DOT)[5] also enables users to configure and reconfigurehow devices control applications. These configurations canbe saved into XML documents and reloaded on demand.Unfortunately, in the current DOT externals for Max/MSPthese configurations have to be loaded by hand; in the De-vice Server default configurations for client applications areloaded automatically so that no human interaction is re-quired.

Other recent frameworks such as the SenseWorld DataNet-work[3] and The Bridge[6] emphasize dynamic registrationof participants and devices in a musical network. The Bridgealso features a decentralized network similar to what isfound in VRPN; there is no central location for monitor-ing and manipulating control data flow. The ability to dis-cover and utilize nodes on a network adds flexibility anddynamism, however, the current lack of recallable configu-rations in these two frameworks makes them less than idealfor VREs in which multiple distinct projects are frequentlyrun.1For a more thorough discussion please seehttp://www.charlie-roberts.com/docs/thesis.pdf

DeviceTracker

DeviceJoystick

DeviceiPhone

Client App

Client App

Client App

Device Server

Analysis Computer

Figure 1: A Sample Device Server Network

2. THE DEVICE SERVER

2.1 OverviewThe Device Server application runs under OS X. It col-

lects data from connected interactive devices and routesthem to registered client applications. All network commu-nication is performed using the Open Sound Control pro-tocol [9]; the ability to send and receive OSC messages isthe only requirement for client applications to communicatewith the server. OSC was chosen as the communication pro-tocol for both its flexibility and its wide rate of adoption intoprogramming platforms used in the digital arts.

Each configuration defines the mappings from devices’controls to application functionality, including arbitrary con-trol data processing (described in Section 2.7), with bothmappings and processing algorithms represented using theLua programming language. Lua was chosen for its speed,dynamism, ability to perform arbitrary computation, androots as a configuration language; more about the decisionto use Lua can be read in sections 2.3 and 2.7 .

Programmers can therefore define entire configurations atthe Lua source code level. Alternately, the Device Server’sGUI allows easy loading, saving, and modification of con-figurations, automatically translating GUI-defined configu-rations into the appropriate Lua code. Client applicationscan also define configurations programmatically by indicat-ing (via OSC messages) which devices they are interestedin and how they want device output to be processed beforeit is sent to them.

The Device Server GUI (described in Section 2.4) alsoallows users to monitor device connections and the dataentering and leaving the Device Server.

2.2 Device Server Network TopologyThe Device Server runs on a single computer in an inter-

active network; Figure 1 shows a simple sample network.Client applications typically running on different comput-ers within the network register with the server by sending ahandshake message that gives the name of the applicationand the port and IP address where the client would like toreceive control messages. Multiple client applications canbe connected to the Device Server concurrently; each clientpossesses its own configuration files defining which devices

Proceedings of the 2010 Conference on New Interfaces for Musical Expression (NIME 2010), Sydney, Australia

58

they will receive data from. These configurations can alsodefine separate Lua functions for processing this data be-fore it is sent to client. Multiple clients can thus receivedata generated by the same controls on the same devicesbut filtered using different algorithms.

Devices can be connected to the Device Server throughmany different mechanisms. Direct connections via cabling,network messages sent via OSC and network messages sentvia VRPN are all supported. Other types of connections canbe accommodated through the use of plugins (discussed inSection 2.5.1).

2.3 ConfigurationThere are four types of configurations utilized by the De-

vice Server and specified in Lua files. Alternatively, the Ap-plication Interface and Implementation configurations canbe specified dynamically using OSC messages at runtime.

• Master Device List - A global configuration that as-signs a unique id to every device in an interactive sys-tem.

• Device Configuration - enumerates the Controls presenton a Device and the range of values each one gener-ates.

• Application Interface - Each client application has asingle Interface that defines what functionalities theapplication is exposing for control, what range of val-ues each functionality expects to utilize, and the OSCaddress for each functionality.

• Application Implementations (aka Configurations) -Client applications can have multiple configurationsthat each address the application’s Interface. Theimplementation file defines which specific controls onwhich specific devices are assigned to each applica-tion functionality, along with the Lua expressions andfunctions for processing control data.

As mentioned above, client applications have a single in-terface file defining the functionalities they expose and anynumber of implementation files defining different configu-rations of devices that feed control data to these function-alities. When an implementation file is loaded the DeviceServer createsmappings that define which controls on whichdevices feed into particular functionalities and what pro-cessing scripts are applied to the data generated by thecontrols. Applications can define implementations that in-clude wired devices instead of wireless ones, multiple usersinstead of a single one, MIDI devices instead of Wiimotesor any other combination of controls. Users can quicklychange entire interactive configurations simply by choosinganother implementation through a pull-down menu in theDevice Server GUI.

A very small example interface is given below for a clientapplication that provides the affordance of moving an avataron a two dimensional plane.

interface = {{ name = "Avatar X", destination = "/nav/a1x",

min = -1, max = 1 },{ name = "Avatar Y", destination = "/nav/a1y",

min = -1, max = 1 },}

In the above interface file two functionalities, Avatar Xand Avatar Y are defined. The application is expecting toreceive values ranging from -1 to 1 for both. The OSC ad-dress where these values should be received is also given.

This information represents constants that are always thesame regardless of what implementation file is currentlyloaded.

Below is an example implementation for the the interface:

mappings = {{ name = "Avatar X", device = "Wiimote 1",

control = "Nunchuk X", expression = ""},{ name = "Avatar Y", device = "Wiimote 1",

control = "Nunchuk Y", expression = ""},}

For each functionality defined in the interface (in this caseAvatar X and Avatar Y) a mapping is defined that denotesthe name of a control on a particular device whose valuesshould be sent to the corresponding OSC address in the in-terface. This is also where Lua expressions can be defined;these will be evaluated whenever data from the correspond-ing control is received by the Device Server. This expressioncan call on predefined Lua functions and enables powerfuldata processing capabilities. The Device Server originallyused XML as its configuration language and JavaScript forcontrol data processing. We decided to move to Lua be-cause it could fulfill both roles; in addition to being one ofthe fastest scripting languages available Lua was originallyintended as a data description language. One of the unan-ticipated advantages to using Lua as the configuration lan-guage is that configurations can be dynamically generated.As one simple example, the for loop below would generatea configuration dictionary that would allow an applicationto access a device with 128 buttons.

controls = {}for i=1, 128 docontrols[i] = {name = "Button Grid" .. i,device = "ButtonDevice",control = "Button " .. i,

}end

Another advantage of using Lua is that the device andcontrol names can be assigned to Lua variables making itvery easy to change one device for another throughout anentire implementation.

2.4 Graphical User InterfaceThe GUI of the Device Server, shown in Figure 2, is one of

the elements that sets it apart from other VR frameworksas well as other tools for musical interactivity. It allowsusers to do the following:

• Quickly see what client applications are connected andwhat controls are assigned to each application func-tionality

• Select the current client implementation file definingcontrol mappings

• Change the devices and controls assigned to applica-tion functionalities via pulldown menus. Changes tocontrol configurations can be saved into new imple-mentation files for future recall.

• Monitor data flow. Users can see the raw data valuesgenerated by the devices and also see processed valuesthat are routed to applications.

• Monitor and manage device connections. The DeviceServer plugin system allows each device to have its

Proceedings of the 2010 Conference on New Interfaces for Musical Expression (NIME 2010), Sydney, Australia

59

Figure 2: A screenshot of the Device Server GUI showing one client application connected to a variety ofdevices.

own encapsulated GUI for managing device connec-tions. This is necessary for devices requiring Blue-tooth pairing or other action sequences to establishconnections.

2.5 Integrating Devices With the Device ServerTo add a new Device that uses a driver or protocol the

Device Server already has a plug-in for (such as HID, VRPNand MIDI) users create a Lua configuration file that enu-merates the device’s controls and gives the range of valueseach control outputs. The Device Server can be extendedto support additional devices and protocols via OSC for-warding or via its plug-in architecture.

OSC forwarding of device data allows devices that areconnected to other computers to be recognized by the De-vice Server. For example, the AlloSphere possesses a cameratracking system that gives the orientation and position ofactive infrared LED markers. The cameras are connectedto their own dedicated computer which performs the com-puter vision processing needed to generate these values.This computer forwards these values to the Device Serverwhich then routes them as required to registered applica-tions. OSC forwarding also allows software applicationssuch as Max/MSP to generate control data to be used bythe Device Server. Thus, if Max has a driver for a devicethat the Device Server doesn’t possess Max can be used toforward messages from that device to the Device Server. Asone example of this the AlloSphere has a bridge mountedin its horizontal and vertical center lined with capacitivetouch sensors. These sensors are mounted on the railingsof the bridge and use a Max/MSP external to analyze theirsignals and forward data to the Device Server via OSC. Ap-plications configured to receive this data can thus tell whenusers are touching the railings and also obtain a rough ideaof user positioning on the bridge.

If a plugin has not been written for a device and thereis no opportunity to feed the device data into the DeviceServer via OSC, a plugin can be written.

2.5.1 Device Server PluginsThe Device Server manages many types of device connec-

tions (MIDI, HID, VRPN) via dynamically loaded pluginswhich can display optional GUIs. The plugin system isdesigned to be open-ended and flexible; there are a widevariety of plugins currently available for the Device Serverranging in complexity from simple HID wrappers to an au-dio FFT analysis plugin that visualizes the bin magnitudesof incoming audio and allows applications to use this dataas control sources. The infrastructure and GUI that allowsthe Device Server to record and play back performances isalso completely encapsulated inside of a plugin.

Although the Device Server comes with many pluginsthey are all compiled optionally so that users don’t have toload plugins they don’t need. An Xcode template projectis included for developers to write their own Device Serverplugins. The template compiles and runs immediately with-out modification in the Device Server; by default it gener-ates a stream of placeholder data that can be easily alteredby developers to use data from C or C++ device-specificdrivers.

2.6 Homogenization of Device SignalsA fundamental goal of the Device Server is for application

functionalities to be agnostic to the devices that controlthem[10]. The implementor of an oscillator should not carewhether the oscillator’s pitch will be controlled by a MIDIkeyboard or a joystick. However, the values generated bya MIDI keyboard (0-127) are different than those of mostjoysticks (-1.0 to 1.0 or -127 to 127). The solution is for theapplication to define its own units for each functionality,e.g., Hertz or MIDI note number, and leave it to the DeviceServer to homogenize the data from differing devices byautomatically remapping them to the declared ranges ofthe application functionalities.

To do this the Device Server finds the application’s de-clared range of input values for each functionality (from the

Proceedings of the 2010 Conference on New Interfaces for Musical Expression (NIME 2010), Sydney, Australia

60

Figure 3: A Screenshot Of The Hydrogen Atom Application

interface file), compares it to the corresponding control’sdeclared range of output values (from the device configu-ration file, and automatically creates an affine mapping toscale and offset values appropriately. This transformationmakes it very simple to change the device/control combi-nation feeding a functionality as the application will alwaysreceive the same range of values.

2.7 Control Data Processing With LuaThe Device Server processes control data via Lua expres-

sions. Every mapping object may have a Lua expression as-signed to it; whenever the control assigned to the mappingemits data the data is passed into the expression and theexpression is then evaluated. Lua expressions may call onpredefined functions to carry out common processing taskssuch as integration and thresholding; these functions canbe reused across multiple applications. The functions areJust-In-Time (JIT) compiled using LuaJIT 2.0[7]. LuaJIT2.0 compilation yields performance that can be comparableto Java and C in various benchmarks. 2 3

A great deal of data is accessible in the scripting environ-ment. Again, Lua scripts are triggered whenever a controlassigned to a mapping generates data. But a script trig-gered by a mapping also has access to data values previouslypassed to other mappings; an expression being evaluatedcan even access the previous values of mappings from otherclient applications. This is useful in many situations; oneexample is when two controls manipulate the same valueat different granularities such as coarse and fine pitch con-trols. Whenever the control assigned to fine pitch is manip-ulated a pitch value should be sent to the client application,but in order for that pitch value to be generated both thecoarse value and the fine value need to be added together.The scripting environment is flexible enough to handle thesetypes of situations.

2http://shootout.alioth.debian.org/3http://dada.perl.it/shootout/

2.8 Recording And Playback Of Control DataThe Device Server allows users to record control data

from performances and interactive sessions. Each controlevent is stored in a simple dictionary that holds an offsettime from when the recording began, device and controlidentification numbers and the value generated by the event.The event sequence can be saved into a Lua file which canthen be edited or loaded and played back in the future.

Performers routinely adjust their gestures to accommo-date fixed gestural mappings to sound synthesis parame-ters. The ability to record and playback gestures makesthe opposite practice possible: sound designers can adjustmappings and synthesis parameters to accommodate fixedgestures. Performance gestures that have been recorded canbe played back repeatedly while sound designers reconfiguresynthesis parameters to yield interesting sonic results. Theability to record and play back timestamped control data isalso useful to researchers conducting HCI experiments.

These recording and playback features are implementedwithin a Device Server plugin, demonstrating that the plu-gin system is useful for purposes other than device drivers.

3. THE DEVICE SERVER AND INTERAC-TIVITY IN THE ALLOSPHERE

There are a wide variety of interactive applications de-ployed in the AlloSphere and all receive their control datafrom the Device Server. These applications include musi-cal works, data visualizations and scientific simulations butmany applications in the AlloSphere blur these lines.

The following research project within the AlloSphere showsthe possibilities of interactive data mining with differentuser and device configurations as enabled by the DeviceServer.

3.1 Multimodal Representation of QuantumMechanics: The Hydrogen Atom

This work, shown in Figure 3, interactively visualizes and

Proceedings of the 2010 Conference on New Interfaces for Musical Expression (NIME 2010), Sydney, Australia

61

sonifies the wavefunction of an electron of a single hydro-gen atom. The atomic orbitals are modeled as solutions tothe time-dependent Schrodinger equation with a sphericallysymmetric potential given by Coulomb’s law of electrostaticforce. Different orbitals of the electron can be combined insuperposition to observe dynamic behaviors such as photonemission and absorption.

The interactive component of the simulation allows one ormore users to fly through the atom with probes that emits“stream particles” that follow along the largest changes inthe probability current and gradient of the electron. Theelectron probability amplitude is sonified by scanning throughgroups of stream particles in the space. The pitch can beadjusted by the rate at which a particular set of stream par-ticles is scanned. By assigning specific pitches to differentfeatures of the wavefunction we can generate musical resultsin the sonification.

The Device Server enables this simulation to be run witha variety of different user configurations and devices. Thedefault configuration is for a single user using a wireless joy-stick to control both navigation and the emission of streamparticles. The most common multi-user scenario is for oneuser to navigate through the simulation while two otherusers control the position of the probes and their streamparticle emission.

Users can experiment with different sets of controls fornavigation and data mining. More experienced computerusers might prefer to navigate through the environmentusing a 6DOF 3Dconnexion Space Navigator while noviceusers use a gamepad. In the hundreds of demos we havegiven we have observed that wireless device communicationwill sometimes inexplicably fail; for this reason we also havea “all wired” configuration to fall back on in the event thatwe experience difficulties with the wireless devices. Switch-ing to this fallback configuration is accomplished through asingle pulldown menu in the Device Server GUI.

While developing and exploring the hydrogen atom repre-sentation, the Device Server helped when transitioning be-tween a single-user desktop environment, where more pre-cise control with a keyboard and mouse is often requiredfor development, and a multi-user immersive environment,where more natural control with wireless tracking devicesand game controls is desired for exploration. The separa-tion of physical control from application logic according tothe Device Server model enforces a “write-once, control any-where” approach to application development that facilitatestransitions between differing working contexts.

Key faculty and graduate student researchers associatedwith the Hydrogen Atom project: Professor JoAnn Kuchera-Morin, Professor Luca Peliti and Lance Putnam.

4. CONCLUSIONS AND FUTURE WORKThe Device Server provides abstractions and functionali-

ties that have significantly eased the challenges of designinginteractive applications for use in the AlloSphere. It allowsinteractive configurations to be easily defined and modi-fied by both novice users and developers. It removes theburden of handling device drivers from application devel-opers and allows them to offload control data processingaway from rendering machines. The Device Server has alsobeen used in performances and research outside the Allo-Sphere; we hope that it will be adopted by the greater mediaarts community and as such have released it as open-sourcesoftware under the MIT license. It can be downloaded athttp://www.allosphere.ucsb.edu/software.php.

Future work includes removing the unnecessary abstrac-tion between devices and applications; both should be thought

of simply as a collection of inputs and outputs. We wouldlike to provide an option to use VRPN as the communi-cation protocol in place of OSC as it is more familiar toVR researchers and computer scientists. We are interestedin the possibility of a Device Server library that could beincluded in applications. This library would allow Lua con-figuration and scripting of control signals but would not re-quire a server or network connection; device drivers wouldbe included in the library as plugins. Finally, we wouldlike to explore the possibilities of making the network moredynamically configurable akin to what is found in the previ-ously mentioned SenseWorld DataNetwork and the Bridgeprojects.

5. ACKNOWLEDGMENTSThis worked was supported by a grant from the National

Science Foundation CreativeIT program.

6. REFERENCES[1] Gadgeteer:device driver authoring guide. 2007.[2] X. Amatriain, J. Kuchera-Morin, T. Hollerer, and

S. Pope. The AlloSphere: Immersive Multimedia forScientific Discovery and Artistic Exploration(HTML). IEEE MultiMedia, 16(2).

[3] M. Baalman, H. Smoak, C. Salter, J. Malloch, andM. Wanderley. Sharing Data in Collaborative,Interactive Performances: the SenseWorldDataNetwork. In Proceedings of the 2009 conferenceon New interfaces for musical expression. CarnegieMellon, 2009.

[4] O. Kreylos. Environment-independent VRdevelopment. In Proceedings of the 4th InternationalSymposium on Advances in Visual Computing, page912. Springer, 2008.

[5] J. Malloch, S. Sinclair, and M. Wanderley. Fromcontroller to sound: Tools for collaborativedevelopment of digital musical instruments. InProceedings of the 2007 International ComputerMusic Conference, Copenhagen, Denmark, 2007.

[6] N. Mitani and L. Wyse. Information Sharing InNetworked Music Application. In Proceedings of the2009 Australian Computer Music Conference, 2009.

[7] M. Pall. The luajit project, 2008. http://luajit.org.[8] R. Taylor, T. Hudson, A. Seeger, H. Weber,

J. Juliano, and A. Helser. VRPN: adevice-independent, network-transparent VRperipheral system. In Proceedings of the ACMsymposium on Virtual reality software and technology,pages 55–61. ACM New York, NY, USA, 2001.

[9] M. Wright and A. Freed. Open sound control: A newprotocol for communicating with sound synthesizers.In International Computer Music Conference, pages101–104. International Computer Music Association,1997.

[10] M. Wright, A. Freed, A. Lee, T. Madden, andA. Momeni. Managing complexity with explicitmapping of gestures to sound control with osc. InInternational Computer Music Conference, pages314–317. International Computer Music Association,2001.

Proceedings of the 2010 Conference on New Interfaces for Musical Expression (NIME 2010), Sydney, Australia

62