Download Collaboration and Embodiment in Networked Music Interfaces for Live Performance PDF

TitleCollaboration and Embodiment in Networked Music Interfaces for Live Performance
LanguageEnglish
File Size12.8 MB
Total Pages188
Document Text Contents
Page 1

Collaboration and Embodiment
in Networked Music Interfaces
for Live Performance
Chad McKinney

Submitted for the degree of D.Phil.

University of Sussex

October, 2016

Page 2

Declaration
I hereby declare that this thesis has not been submitted, either in the same or different

form, to this or any other university for a degree.

Signature:

Supervisors: Dr. Nick Collins & Dr. Martin Berger

Examiners:

Page 94

Chapter 5. An Interactive 3D Networked Music Space 82

Figure 5.5: Three looping sequencers on an island. When the sequencers land on white triangles
a synth onset is triggered.

SuperCollider is an excellent choice for sound design because it has an established code

base with years of active development and supplies a well defined and terse interface for

synthesis. Shoggoth can be used to create a wide range of sonic output, but given the loop-

ing sequential infrastructure and the often aggressive waveforms produced by the wave

terrain synthesis, rhythmic noise is the most natural end result. While this style of music

may not appeal to all, generative and networked music audiences are often interested in

more experimental music.

5.5 Networking
The Shoggoth network implementation is very similary to Yig, using Open Sound Con-

trol (Wright, 2002) messaging with OSCpack (Bencina, 2013) to create and receive OSC

packets and the OSCthulhu (McKinney & McKinney, 2012) server and client framework

to synchronize state. In Shoggoth there are eight types of information networked: Player

position, player orientation, terrain height maps, terrain step grids, sequence positions, se-

quence sizes, synth selections for sequences, and chat. This group contains a wide variety

of data from character strings to high volume meshes. The terrain meshes proved to be the

most challenging to network initially. Synchronizing 10,000 triangles with 3 points each

as well as the step grid was daunting, inspiring odd attempts to reduce bandwidth such

as using LZMA compression (Salomon, 2006). The solution was limiting and ultimately

unused. Instead of manually synchronizing each triangle, instead the settings and random

seed used to generate a given terrain mesh and step map were synchronized, allowing

for an incredibly small amount of information to guarantee state across the network. The

drawback is that manual deformation of the terrains had to be removed, leaving only the

Page 95

Chapter 5. An Interactive 3D Networked Music Space 83

generative processes able to create and manipulate the islands. This changed the nature

of the performance from guided intentionality to fast experimentation, but the reduction

in bandwidth was extremely beneficial.

Player position and orientation were easy enough to network, but using seven argu-

ments per user to define them (3 for position, 4 for quaternion defined rotation) some-

times generated asynchronous updates for their individual components and unnecessary

traffic. This problem led to the use of bitpacking to package updates together. Using

bitpacking the X/Y/Z components of the position of a player can be packed into a single

integer value, as well as the W/X/Y/Z components of their rotation, reducing traffic while

simultaneously enforcing unified updates. The same technique was used with the afore-

mentioned island states. All the settings including the process number and random seed

are packed into a single integer so that there is a guaranteed success or failure of an up-

date. This prevents scenarios where only a portion of the information needed to update an

island is received, while the others might be lost, resulting in an incorrect state. Because

of these efforts, Shoggoth’s networking is precise and fast despite the large amount of

information represented on screen and even while using low quality wireless connections.

5.6 Categorization
As in the previous chapter with Yig, here is a set of classifications of Shoggoth according

to several network music taxonomies including Alvaro Barbosa’s network music classifi-

cations (Barbosa, 2003), Andrew Hugill’s internet music taxonomy (Hugill, 2005), Gil

Weinberg’s enumeration of network configurations, Golo Föllmer’s twelves types of net

music (Föllmer, 2005) and Thor Magnusson’s epistemic dimension space (Magnusson,

2010). Starting with Barbosa’s network music classification, Shoggoth is similar to Yig in

this taxonomy. While Shoggoth has the capacity to support asynchronous interaction, the

system was designed for synchronous collaborations and performances, and lacks impor-

tant features for asynchronicty such as state storage and recall. On the other hand the live

configurations of patterns and synth parameters coupled with the client and server archi-

tecture highly encourages synchronous interaction. Similar to Yig, Shoggoth can be used

both locally and remotely, as the networking was written to handle large distances. Simi-

lar to Yig, local performances may benefit from using a single computer’s output for signal

as some highly chaotic feedback sounds can producte different results across machines,

although this may be an aesthetic choice as the layering may be considered to be a useful

dimension to the performance. Barbosa labels music that has synchronous interactions

but with local and remote locality as ‘Shared Sonic Environments’, which is especially apt

given the three dimensional virtual space that Shoggoth performances inhabit.

Next, with Hugill’s Internet music taxonomy, Shoggoth sits well in the second category

of music that is Created or Performed in Virtual Environments, or Uses Virtual Instruments.
Convincing arguments could be made that Shoggoth also facilitates music that Uses the
Internet to Enable Collaborative Composition or Performance, but the defining features of
Shoggoth align more closely with most of the pieces that could fit into Hugill’s second

Page 187

Appendix D. Quick Live Coding Collaboration in the Browser XLII

4
1
%

4
1
%

2
4
%

1
8
%

0
%

4
7
%

2
4
%

6
5
%

7
1
%

1
0
0
%

1
2
%

3
5
%

1
2
%

1
2
%

0
%

re
sp

on
se

I
w

il
l

u
se

L
ic

h
.j
s

in
a

f
u

tu
re

p
ro

je
ct

T
h

e
b

ro
w

se
r

b
as

ed
i

m
p

le
m

en
ta

ti
on

i
s

u
se

fu
l

It
w

as
d

if
fi

cu
lt

t
o

co
m

m
u

n
ic

at
e

an
d

c
ol

la
b

or
at

e

I
q

u
ic

k
ly

b
ec

am
e

sk
il

lf
u

l
w

it
h

L
ic

h
.j
s

L
ic

h
.j
s

is
u

se
fu

l
fo

r
m

u
si

c
co

ll
ab

or
at

io
n

1
0
0

5
0

0
5
0

1
0
0

P
er

ce
n

ta
g

e

R
e
sp

o
n

se
1

2
3

4
5

6
7

Page 188

Appendix D. Quick Live Coding Collaboration in the Browser XLIII

Figure D.2: Generative visuals created with Lich.js

Similer Documents