~Proceedings ICMCISMCI2014 14-20 September 2014, Athens, Greece
Figure 2. Pebble's accelerometer data integrated in urMus' dataflow engine and visible in its default interface as
PAccel X, Y, and Z. The patch shows each accelerometer
axis connected to a separate sine oscillator.
be called with arguments that contain the three-axis accelerometer data. An example Lua code to receive pebble
accelerometer data follows:
function ReceivePebbleData (self,
-- x, y, z contain
-- pebble accelerometer data
DPrint(x.." ".. y.." "..z)
-- Simply printing the numbers
end
x, y, z)
pr = Region ()
pr:Handle ("OnPebbleAccelerate",
ReceivePebbleData)
We have used this second version to realize the MoveOSC
iOS application. urMus uses a normed data format of -1to
1 [20]. The accelerometer data is received in X, Y, Z coordinate form using this range and is then normalized to a
valid OSC value between zero and one.
MoveOSC is designed to make Pebble easy to use as a
controller. For this reason its visual presentation is simple
and directed at facilitating quick setup of connections to
the smart watch on the one hand, and a remote OSC application on the other. The user interface design can be seen
in Figure 3.
6. CONCLUSIONS AND FUTURE WORK
In this paper we described the design of a mobile app that
enables the use of a bluetooth enabled smart watch with
accelerometer sensors (Pebble) to be used as a generic gestural controller for music. We provide generic OSC connectivity offering broad applicability of the watch as a controller. Further, we integrated the watch with a mobile music environment allowing direct design of mobile-centric
musical performances. Current restrictions include limits
of the hardware with respect to CPU power.
A number of extensions to MoveOSC are thinkable. For
example, the magnetometer data could also be made avail
Figure 3. MoveOSC's iOS app screens for instruction and
configuration.
able for performance in a similar way as discussed for accelerometer data here. The reason why we have not explored this option yet are the CPU and bandwidth issues
discussed. However we anticipate that with hardware evolution this obstacle will disappear. Furthermore, feedback
to the performer could be incorporated. A backchannel
communication triggering vibrotactile or visual display can
alert the performer of relevant aspects of the performance,
such as a beat pulse, or a section transition. Finally, we
hope that smart watches will follow the evolution of smart
phones and become increasingly sensor-rich, incorporating additional sensors of interest for musical performance,
such as gyroscope sensors, visual sensing, and microphones.
Some of these trends can already be observed in emerging
technologies. For example, the Samsung Galaxy Gear contains both a microphone and a camera. Hence the performance spectrum of smart watches may well be expanded
drastically with future generations of this commodity technology.
We believe that commodity smart watches are a promising technological vehicle to enable musical performance,
following the footsteps of Wiimotes [21, 22] and multitouch smart phones [12] as enablers of creativity with broadened accessibility. For example ubiquity of smart watches
would imply that it is easier to develop augmented dance
pieces for practitioners who do not have access or expertise to custom hardware solutions. Audience participation
involving gestures become more viable as audience members may well already possess the hardware. Distribution
of technology for classroom teaching purposes becomes
easier as getting the technology is not hindered by the limits of custom production.
6.1 Acknowledgments
Many thanks to Takumi Ogata for his help integrating MoveOSC
with Ableton Live for a musical performance.
References
[1] B. Bongers, "Physical Interfaces in the Electronic
Arts," in Trends in Gestural Control of Music, M. M.
- 695 -
