~Proceedings ICMCISMCI2014 14-20 September 2014, Athens, Greece
action. In SWARMED [3], the authors developed a framework for audience interaction during an installation accessing a website on captive portal. The novelty of using a
captive portal is interesting on the aim of focusing user's
Internet access only to the performance application during
the presentation. On the other hand, the author notice that
each participant would like to hear its contribution to the
performance, but all the sounds are reproduced only on the
central performer, and it is hard to give this feedback if lots
of people is participating.
On NEXUS [4] project, that is related to distributed performance, authors attempt that a cross-platform application can really be conceived using dynamic web page, allowing server side web application to do the hard work
while the participants interact using an interface placed
into a browser on its own device. Even if both works use
Ruby on Rails, NEXUS leaves the application on line for
distribution and scalability facilities aiming a large number
of participants from different places.
On the other hand, we have urMus [5], an environment
for mobile application development. This is a directly related work that has an event-handling for mobile sensor
events, with lots of features that permits easy musical application development. It is possible to load scripts and
also share code between users over the network in some
applications developed with urMus [6]. The only limitation
for musicians is that Lua isn't used as Csound and Pure
Data.
Another related work uses Csound as main patch language [7]. The users loads Csound orchestras and scores
on mobile devices and uses interface options and some sensor events for interaction. This approach was a motivation
for this work, and we also notice some advantages of a
similar project, PdDroidParty i as inspiring for a new way
of musical interaction using a common language for musicians and some transparent information presented below.
3. TRANSPARENT INFORMATION
There are lots of transparent information that can be used
on mobile applications, and we are going just to cite some
of them briefly:
" Available WiFi networks can be found everywhere,
and the users are living the Always-On Era;
" The cost for send and receive short informations from
web servers is becoming unimportant bearing in mind
the price of 3G plans on most part of the world;
" Push notifications are being used by the most of the
applications installed on mobile devices, aiming to
keep the user updated, but always consuming users
Internet connection as much as possible;
" The use of hot-spot informations to facilitate localization has been a used first with robots, but also by
general systems like Google Maps.
Thinking about those premises we can conclude that we
can extrapolate the usual limits of performances on a theater, with lots of mobile users, for example, considering
1 PdDroidParty: http: //droidparty.net
"transparency" in the user point of view. Of course the
user need to know that we are using those information, but
it does not need to be explicitly during the performance.
4. SENSORS2PD
The integration of PD with Android application became
possible with libpd, a library that grant loading patches and
exchange messages using senders and receivers on applications. One of the drawbacks of this integration is a slight
need of Java programming experience intended for Android application development. Apart from that situation,
some native applications have been developed to smooth
the way for non (Java) programmers use its own patch on
Android devices. The most famous application with this
concept is PdDroidParty. This application searches internal storage for patches and permits interaction using some
interface options. Although it is a great solution, it does
not facilitate the use of sensors with patches.
Android devices possess lots of sensible sensors that have
been used on many situations. We notice that the quantity of sensors and its range vary based on device and also
Android API, resulting in some restrictions during mobile
performances if you want to use specific sensors or have
different devices. Our approach try to solve these problems and presents other sensor's information that can be
used.
4.1 Using sensors on Pure Data patches
Sensors2PD is an application that makes possible the use
of all Android sensors and even more useful data from device functionalities. The application uses libpd 2 to load
the patch that users can seek and select from mobile storage. Receivers for any sensor value can be used on the
patch following the specification found on the guide. Depending on the sensor id (ID) and variable number (#), you
need to configure the receiver like that:
[r sensorlDv#]
If you want to use Accelerometer, which has ID=1 and 3
variables, you can receive the sensor values using:
[r sensoriv0]
[r sensorv]
[r sensorv2]
This is a reasonable approach considering that the application will be listening for any sensor variation and might
send its updated value to the patch as fast as possible. Android sensors can be listened at four different rates, varying
from 0 to 200ms. The fast you retrieve values the fast you
drain the battery on mobile application, but during some
tests we've found out that it is not a problem to use the
fastest mode if the normal time of a performance or instal
lation won't be more than one hour. Despite the fact that
not all the sensors are supported on all devices, it is not a
2libpd: http://libpd.cc
- 745 -
0
