Organised Sound 10(3): 233–242 2005 Cambridge University Press. Printed in the United Kingdom. doi:10.1017/S135577180500097X
Public Sound Objects: a shared environment
for networked music practice on the Web
ALVARO BARBOSA
Music Technology Group (MTG), Pompeu Fabra University, Calle Ocata 1, 08003 Barcelona, Spain
Research Center for Science and Technology of the Arts (CITAR), Portuguese Catholic University, Rua Diogo Botelho 1327, 4169-005 Porto,
Portugal
E-mail: abarbosa@{iua.upf.es, porto.ucp.pt}
The Public Sound Objects (PSOs) project consists of the
development of a networked musical system, which is an
experimental framework to implement and test new concepts
for online music communication. The PSOs project
approaches the idea of collaborative musical performances
over the Internet by aiming to go beyond the concept of using
computer networks as a channel to connect performing
spaces. This is achieved by exploring the internet’s shared
nature in order to provide a public musical space where
anonymous users can meet and be found performing in
collective sonic art pieces.
The system itself is an interface-decoupled musical
instrument, in which a remote user interface and a sound
processing engine reside with different hosts in an extreme
scenario where a user can access the synthesizer from any
place in the world using the World Wide Web. Specific
software features were implemented in order to reduce the
disruptive effects of network latency, such as dynamic
adaptation of the musical tempo to communication latency
measured in real time and consistent sound panning with the
object’s behaviour at the graphical user interface.
1. INTRODUCTION
Research work in the networked music field has
recently been published in surveys by Álvaro Barbosa
(2003), Gill Weinberg (2002) and Dante Tanzi (2001)
which describe and categorise several different sys-
tems, following diverse architectures and practice
contexts. Networked music can extend the boundaries
of performance for practising musicians or in com-
munity practice performed by general and possibly
non-musician users.
Connecting performing spaces for practising musi-
cians to collaborate over long distances is the current
popular approach that has facilitated most work per-
formed and generally is implemented over a peer-
to-peer architecture. Many examples of bilateral
transmission of audio for geographically displaced
musical events can be found, such as the Sensorband
ISDN (Bongers 1998) concerts, the Hub remote con-
certs (Gresham-Lancaster 1998; Brown and Bischoff
2005) or the Internet 2 multi-channel music sessions
performed in several occasions over the United States
and Canada (Woszczyk et al. 2005). Some other
systems have been custom developed for similar col-
laborative scenarios, using control data for communi-
cation amongst performers instead of encoded digital
audio streams. Examples of such systems include the
transMIDI, which allows musical performers (and
listeners) to play together or to organise into multiple
session groups, by performing on their MIDI control-
lers, or a number of electronic music software imple-
mentations (MAX/MSP, PD, Reacktor, etc.) that
support Mat Wright’s Open Sound Control protocol
(Wright and Freed 1997).
Commercial solutions addressing the professional
recording and rehearsing studio paradigms, such as
the early 1999 ResRocket Surfer (Moller et al. 1994)
or the recent ejamming software (Nelson 2005), tend
to incorporate both types of communication data
(digital audio and MIDI), but since the intention of
such systems is to serve general communities of
users, a centralised shared system of community
groups for textual communication (chats) is usually
incorporated.
In fact, the idea of a shared sonic environment is
bounded to public musical practice performed by gen-
eral and possibly non-musician users on the Net. This
is a recent approach to networked music and therefore
existing examples are usually preliminary systems
based on diverse sonic aesthetics and user interaction
models; however, there is a tendency for implementa-
tions based on client-server topologies. This derives
from the fact that a shared virtual environment is an
ongoing instance wish that must be permanently avail-
able for users to login and interact with whoever is
present at that moment. Examples of projects that
follow this approach are Atau Tanaka’s mp3Q Piece
(Tanaka 2000), a shared online sound space on the
Web that streams multiple channels of mp3 audio
from different servers from which users can manipu-
late the sources by actuating over a graphical represen-
tation of the system behaviour, recent projects based
on TransJam Server (Burk 2000), such as Phil Burke’s
webdrum (Burke 2000), Chris Brown’s Eternal Net-
work Music (Brown and Bischoff 2003), Max Neu-
haus’ Oracle (Neuhaus et al. 2005), and the Public
Sound Objects project, designed since 2002 by the

234 Alvaro Barbosa
author at the Music Technology Group in Barcelona
with the purpose of providing an experimental study
framework for shared sonic environments in the
context of the Interactive Systems Group research
activities.
2. THE PUBLIC SOUND OBJECTS PROJECT
The Public Sound Objects (PSOs) project is web-based
collaborative virtual environment focused on music
performance, developed at the Music Technology
Group of the Pompeu Fabra University. This
project has provided an experimental framework
in order to implement and test different approaches
for online music communication. A preliminary
specification of the system was published in Barbosa
and Kaltenbrunner (2002), and the first prototype
was implemented in December 2002. The PSOs
system is publicly available online from the URL:
http://www.iua.upf.es/~abarbosa/. Conceptually, it
explores the notion of a shared Web space for commu-
nity music creation, and that of an art installation,
bringing together physical space and virtual presence
in the Internet. The system aims to allow synchronous
interaction providing a platform for sonic joint
improvisation amongst Web users.
The overall system architecture was designed with
respect to the following key factors: (i) it is based on
a centralised server topology supporting multiple
users connected simultaneously and communicating
amongst themselves through sound; (ii) it is a perma-
nent public event with special characteristics appeal-
ing both to a ‘real world’ audience and to an online
virtual audience; (iii) the user interface and the sound
synthesis engine offer a constrained sonic creation
paradigm, which provides some coherence between
the individual contributions; and (iv) the system is
scalable and modular allowing future expansion and
different set-ups.
In this system the raw materials provided to the
users for manipulation during a performance are
sound objects. The definition of a sound object as a
relevant element of the music creation process goes
back to the early 1960s (Schaeffer 1966). Schaeffer
defined a sound object as ‘any sound phenomenon or
event perceived as a coherent whole (. . .) regardless
of its source or meaning’ (Chion 1983). From a psy-
choacoustic and perceptual point of view, Schaefer’s
definition is extremely useful, since it provides a very
powerful paradigm to sculpt the symbolic value
conveyed in a sonic piece.
In the PSOs system a server-side real-time sound
synthesizer triggers a sound object according to the
user’s action. Since the feedback from other user’s
performance is strictly auditory, the characteristic
which makes a sound object distinguishable from the
overall soundscape is the key element that permits the
awareness of the individual action of a user over his
sound object.
3. THE PSOS ARCHITECTURE
The PSOs system is composed of the PSOs server
and multiple PSOs clients. Clients control a visual
interactive interface, while the server controls all
computation regarding the sound synthesis and trans-
formation. It is an extreme example of an interface-
decoupled application where the synthesis engine is
separated from the user interface over a large area
network (Barbosa, Kaltenbrunner and Geiger 2003).
Clients communicate with the server through HTTP
by sending and receiving packets of data. There are
several types of data packets that the clients can send
but the most important ones are the ImpactPacket –
which informs the server that the bouncing ball has hit
one of the walls; the ControlPacket – which tells the
server that the user has changed the value of one of the
interface controls; and the PingPacket – which is used
to measure the network delay between the client and
the server.
The server packets are received by a Web applica-
tion that reroutes them to the interaction server – a
module of the PSOs server that manages clients,
instruments and the events generated by the PSOs
client. Depending upon the type of data packet
received, a sound can be generated by the synthesis
and transformation engine and then streamed back to
the client by the streaming audio server, or the visual
representation of the client can be updated at the
installation site by the local visual representation
engine, or both.
Server and clients are of different modules:
3.1. HTTP server
Clients connect to the PSOs server through standard
HTTP connections. Although our initial choice was to
implement UDP-based communications – faster than
a TCP-based protocol like HTTP – the idea had to be
abandoned for two main reasons:
• Most firewalls block all unknown UDP traffic,
which would mean that a great number of users
would not be able to access our server, also
increasing the difficulty of deploying the PSOs
server for the same reasons: UDP traffic would
have to be allowed at a specific port by the
firewall.
• Some browsers’ security policies for Java applets
only allow them to make connections using the
HTTP protocol.
In order to overcome these restrictions, a communi-
cation system was realised using a ‘firewall generally
allow’ protocol: HTTP. For this a server application