# Designing a distributed musical instrument for collective improvised interaction

Aliénor Golvet, Benjamin Matuszewski, Frederic Bevilacqua

► To cite this version:

Aliénor Golvet, Benjamin Matuszewski, Frederic Bevilacqua. Designing a distributed musical instrument for collective improvised interaction. AM '24: Audio Mostly 2024 - Explorations in Sonic Cultures, Sep 2024, Milan, Italy. pp.405 - 420, 10.1145/3678299.3678341. hal-04867345

HAL Id: hal-04867345

https://hal.science/hal-04867345v1

Submitted on 14 Jan 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

# Designing a distributed musical instrument for collective improvised interaction

Aliénor Golvet

STMS-Ircam-CNRS-Sorbonne

Université

Paris, France

alienor.golvet@ircam.fr

Benjamin Matuszewski

STMS-Ircam-CNRS-Sorbonne

Université

Paris, France

benjamin.matuszewski@ircam.fr

Frédéric Bevilacqua

STMS-Ircam-CNRS-Sorbonne

Université

Paris, France

frédéric.bevilacqua@sorbonne-

universite.fr

## ABSTRACT

In this paper, we present Simone, a distributed musical instrument for collective improvisation created using a research through design approach. The collective interaction with Simone is performed through different interaction scenarios specifying how data is exchanged between users on the local network. First, we present the design and implementation of Simone including the audio synthesis system and the different scenarios. Then, we present a study with groups of expert users, asking them to improvise collectively with Simone to observe their appropriation of the instrument and how they interact collectively. Qualitative data analysis shows that the process of appropriation is a complex phenomenon that depends on participants’ musical background and experience and is a preliminary condition for collaboration. Additionally, our results reveal participants’ perception of networked elements and the influence it had on their collective interaction. Finally, we discuss the design of collective interaction and distributed music instruments.

## CCS CONCEPTS

* Applied computing → Sound and music computing; * Human-centered computing → Collaborative interaction.

## KEYWORDS

sound and music computing, improvisation, musical instrument, collective interaction

### ACM Reference Format:

Aliénor Golvet, Benjamin Matuszewski, and Frédéric Bevilacqua. 2024. Designing a distributed musical instrument for collective improvised interaction. In *Audio Mostly 2024 - Explorations in Sonic Cultures (AM '24), September 18–20, 2024, Milan, Italy*. ACM, New York, NY, USA, 16 pages. https://doi.org/10.1145/3678299.3678341

## 1 INTRODUCTION

The rise of the Web Audio API [1] since 2011 has accelerated the development of web browser based music systems and the emergence of new collective musical experiences. Drawing from a decades old tradition of artists working in the field of “network music” [12],

these works explore the various possibilities offered by networks: remote musical performance, audience participation, sensor integration, virtual reality systems [47].

While the NIME (New Interfaces for Musical Expression) community has for several years been interested in questions of instrument design and appropriation [27, 53], most of the works in this field concerns practices where musicians use their own interfaces without necessarily being collectively connected by a network. The question of instrumental design of networked musical systems in *co-located situations*, and the learning and collective appropriation of such *distributed* systems by musicians, still needs to be further explored.

In this paper our goals are: 1) to design a distributed digital music instrument oriented toward musical improvisation and featuring collective interaction, 2) to observe the appropriation of this instrument by groups of expert users (i.e. improvising musicians with digital means) 3) to reflect on the design process of this instrument through the observation and interviews of users.

In the field of computer science, the term “distributed system” describes a decentralized system in which computing is performed on multiple computers connected via a network and able to communicate messages and data between each other. Following Van Steen and Tanenbaum, the different elements of the distributed system should “appear to its users as a single coherent system” [48]. In this paper we define distributed musical instruments as networks of interactive devices that communicate and coordinate their action to produce music thus creating potential for many collaborative and collective interactions. While the term distributed system may also refer to systems operated by single users (or no users at all), in this paper we focus on the case of instruments operated by multiple performers simultaneously.

The term “musical improvisation” encompasses a large number of musical traditions. In this paper we focus on what is usually called “free improvisation” or “free music” or even “non-idiomatic improvisation”. Unlike other forms of improvisation that follow an idiom, for instance those of jazz or Indian classical music, and often rely on a particular harmonic or modal framework, free improvisation has been described by musician Derek Bailey as having “no prescribed idiomatic sound”. Bailey adds that “the characteristics of freely improvised music are established only by the sonic-musical identity of the person or persons playing it” [2].

We decided to focus on non-idiomatic improvisation for multiple reasons: 1) We aim to observe what elements foster collective interaction when using a distributed instrument outside of the presence (in idiomatic musical practice) of a predetermined structure that

<figure><img src="image_3.png" /></figure>

This work is licensed under a Creative Commons Attribution International 4.0 License.

AM '24, September 18–20, 2024, Milan, Italy
© 2024 Copyright held by the owner/author(s).
ACM ISBN 979-8-4007-0968-5/24/09
https://doi.org/10.1145/3678299.3678341
works as “a constraint and a resource for intra-personal coordination (for the soloist) and inter-personal coordination (for all the members of the group)” [39]. 2) The open-ended nature of free improvisation leaves room for a plurality of strategies and musical outcome as Saint-Germier et al. note, “a same ensemble in the same context can generate extremely different musical contents on the basis of the same general collective intention of freely improvising music together” [39]. We expect that participants of our study might explore different strategies that could help us to gain a more general understanding of our system uses. 3) By not prescribing any type of interaction, it gave us more flexibility in the design of our instrument and on the forms of distributed interaction that could be imagined.

Thus, we consider musical creation and more particularly musical improvisation as a stimulating situation where decisions and changes made during the design of the artifact can produce effects that cannot be fully anticipated. Hence, we assume a personal approach to design that is informed by our experience as users and designers of musical interfaces as well as our personal aesthetic preferences. This implies that the design of our system carries a fair load of personal choices. In return, we employ a reflexive point of view in the analysis of the qualitative data we collected by observing how these personal choices interact with users’ experience.

While the design and development of a musical instrument is in itself a contribution of our work, there is debate in the design community on the epistemic value of design artifacts and whether or not we can devise general knowledge from it. For example Gaver asserts that “however valuable generalised theory may be, [...] it is the artefacts we create that are the definite facts of research through design” [18] and Zimmerman and Forlizzi instead suggest that “the artifact functions as a specific instantiation of a model - a theory - linking the current state to the proposed, preferred state” [55].

Following these remarks, we follow a research through design approach as “forms of making centred around knowledge and understanding that has formed in relation to a certain kind of judgment characterized [...] by starting from the particular” [35]. Hence, we aim that our system serves as a tool from which can emerge insights and questions on a wider scale on the design of a collective instrument and on distributed musical interactions. Moreover, following Findeli’s statement that “the ‘conception’ part is only one of the two main moments or constituents of a design project, the ‘reception’ part being the other” [15], the instantiation of our prototype in actual situations is also one of our objectives.

Therefore, this paper contains two main contributions: The first one is the design of Simone, a web-based system for co-located distributed collective improvisation (Section 3) controlled by vocal inputs. Simone is declined in multiple interaction scenarios in which the network plays a different structural role and users exchange different types of information. We describe both the conception of Simone as well as how it was influenced by previous networked musical systems and musical aesthetics close to sound collage, musical improvisation and *musique concrète*.

The second contribution lies in an experimental study in which we invited groups of expert users to improvise with Simone collectively (Section 4). We present results from this study from which we collected qualitative data through semi-structured interviews

with groups of users about their appropriation of the instrument and their collective interactions with the system (Section 5).

Finally, we draw from these results to reflect on the design of Simone and more generally on the design of collective musical instruments (Section 6).

## 2 BACKGROUND

Networked music performances have been described as exploring new ways of distributing cognitive resources and information within a group [34, 41]. It aims for example at modifying interactions and individual playing depending on the agentivity of other musicians and the network itself, breaking down the separation between musicians and audience, or implementing collective creative processes rather than the production of a fixed work [24, 50]. In this section, we present a non-exhaustive list of some examples of networked music systems that served as direct inspirations in the design of our system. We deliberately do not cover works that involve “telematic performance”, “telepresence” or Virtual Reality [26, 33] and instead focus on the case of co-located systems. Indeed, these two approaches cover very different conceptual and technical concepts. While the core challenge of telematic performance is the streaming and synchronization of audio signals, this is a trivial or useless task in co-located cases where the emphasis is laid on the sharing of controls or non-audio data and on “situated interactions, occurring in a shared physical space” [3].

The pioneering and paradigmatic example of such use of the network is the band *The Hub*, founded in 1986 following the *League of Automatic Music Composers* [19, 44]. Although each musician in the group controlled a system of his own making, their performances were based on the exchange of information via a local network according to a communication protocol defined for each piece. For example, in the piece *Waxlips* (1991), each musician receives individual notes from the other band members via the network. This musician must first play the note received, then apply an arbitrary transformation before sending it to another member of the group. We reused this idea in Simone by implementing different interaction scenarios that define communication channels between players and the server. *The Hub’s* experiments served as a model for many music ensembles, so-called *laptop orchestras*, in which the network infrastructure had more or less aesthetic importance [12, 46, 49].

Following a distinction made by Rohrhuber [37], we can distinguish two types of structures for the sharing of information within a networked music system: either simultaneous access to a common, shared state, or the sharing and circulation of objects and information within the network.

In the first category, we can mention *Emupo* [11], an interface for collective musical improvisation developed in Max/MSP. Intended to be played autonomously or to complement other instrumentalists, *Emupo* can be controlled by several users at once, each taking control of different parameters in the production of the same sound, giving rise to "intra-instrumental" interaction.

In the second category, the *powerbooks unplugged* ensemble [38] offers group performances based on circulation of distributed states containing code extracts, musician comments and messages triggering the production of sound events on the loudspeakers of any computer on the network. The example of *powerbooks unplugged*
also highlights another advantage offered by the decentralized aspect of sound production: the possibility of freely choosing the way in which sound is spatialized, and a flexible number of musicians.

The design of Simone is more influenced by the decentralized approach of the second category although it could be argued that some interaction scenarios could be imagined to make it pertain to the first category.

Some other examples of distributed instruments were influential to us in the way they used vocal inputs to control sound synthesis. Gil Weinberg's *Voice Networks* (2003) [50] is a collaborative music installation that allows non-expert users to take part in a collective music-making experience, highlighting the social aspect of group play. The installation comprises four stations arranged in a square, facing each other, with a screen in the middle. Each station is equipped with a microphone, a touchpad controller and loudspeakers. Participants can record sound loops with their microphones and apply sound transformations to them using the touchpad which controls a Max/MSP patch. The network is used to exchange sound loops created between participants. The technical configuration of *Voice Networks* and the prominent use of vocal loops served as inspiration for the design of our system.

Designed by Max Neuhaus et al., *Auracle* (2004) [16] is a collaborative synthesizer accessible on the Internet. The system analyzes the sound captured by each user's microphone and extracts several types of data at different levels (audio descriptors; classifications of vocal "gestures" by principal component analysis) to control a synthesizer. This idea was used as an inspiration in the design of the audio engine of Simone. Auracle is designed as a system that responds to user activity and seeks to encourage non-verbal communication and dialogue through a musical experience accessible via an interface aimed at a non-expert audience.

# 3 DESIGN OVERVIEW

Inspired by some of the above-mentioned work, we have developed Simone, a distributed instrument for co-located collective improvisation.

Our main objective was to design a collective music creation system that encourages improvisation, that uses voice in the sound synthesis process, and that relies on the exchange of information via the network. The system is conceived as an experimental ground to study various paradigms of collective interaction and their approach by musicians. It must therefore be quickly accessible, yet possess the necessary depth and flexibility so that they don't feel restricted in a context of improvisation and creation.

Simone implements different interaction scenarios (cf. section 3.2), which propose variations in terms of their interfaces and of the interaction topologies [30] implemented. Nonetheless, each scenario shares a set of common features:

(1) The microphone is used as a medium through which sound synthesis is controlled.

(2) Sound synthesis is based on the principle of audio mosaicing (cf. section 3.1).

(3) The system uses a local network to share information between agents (i.e. users and terminals).

The type of transmitted information (synchronized clock, audio files, analysis data, etc.) depends on the chosen scenario.

Simone has been entirely developed with web technologies using the *Soundworks* framework [29] made for developing multimedia distributed applications using JavaScript. *Soundworks* handles creation of the server and clients, management of distributed states and communication between server and clients through WebSockets. The audio synthesis engine has been developed entirely with the Web Audio API.

## 3.1 Sound synthesis and vocal inputs

Sound synthesis in Simone is performed using a technique close to granular synthesis [36] and concatenative synthesis [43] known as *audio mosaicing* [22, 54]. This technique, which can be seen as the audio analog to the more widespread concept of photomosaics (cf. Fig. 1), consists in reconstructing an audio signal (thereafter named the *model signal*) with elements from another signal (the *generator signal*).

To do this, the *model signal* is cut into small audio segments (called *grains*). For each grain, we look for the most similar grain in the *generator file*, according to a chosen metric and audio descriptors. The resulting sound is the concatenation of grains from the *generator signal*. The synthesized sound then follows the temporal evolution of the *model signal* but with the timbre of the *generator signal*.

In the case of Simone, the similarity between grains is computed according to the distance between their vectors of Mel Frequency Cepstral Coefficients (MFCC) which are multi-dimensional features used to describe an audio signal. MFCC are particularly well suited to the analysis of speech and are useful to capture timbral characteristics of sound [32]. Additionally, we compute the Root Mean Squared (RMS) energy of each grain of input signal which is mapped directly to the volume of the output signal to preserve the dynamics of the input signal. This was added after users' in a pilot study we conducted mentioned that they found it sometimes difficult to perceive a link between the *model* sound they recorded and the sound that was played by the synthesis engine.

We chose to rely on audio mosaicing in Simone for multiple reasons. First, while one of our objectives was to explore the use of vocal inputs to control a music instrument, we still wanted Simone to be accessible to users who may feel uncomfortable to use their voice in a collective improvisation context. Indeed, as Weinberg noted by observing how users would use *Voice Networks*, "regarding the choice of the voice as an intuitive and malleable gateway for creative and collaborative interaction, it was interesting to observe that although the voice is probably the most intuitive and prevalent means of communication in everyday life, some participants were inhibited to use it in a public installation setting due to its "committing" or "revealing" nature or perhaps due to common "stage fright.""[50]. Because in Simone the voice is completely altered by the mosaicing process, we assumed this would mitigate this effect.

Moreover, because audio mosaicing eschews most traditional musical concepts such as rhythm or harmony, we presumed it would be well adapted to the task of free improvisation in which the focus is put on concepts of timbre and textures [21, 40]. We also presumed it would foster a more exploratory stance when playing and provide a low barrier to entry and a sense of learning.
<figure><img src="image_4.png" /><figcaption>Figure 1: An example of a photomosaic and the analogy with audio mosaicing</figcaption></figure>

Finally, audio mosaicing is relatively easy to implement compared to other synthesis techniques, which allowed us to focus on interface design and made early prototyping quicker and more flexible. While similar in results to timbre transfer methods by machine learning [31], audio mosaicing requires much lower computing power and can be easily implemented using the Web Audio API making Simone readily available on a large variety of devices (computers, laptops, tablets or even mobile phones).

## 3.2 Interaction scenarios

In order to guide collective interactions and inspired by The Hub's definition of communication protocols as a method of composition, Simone is declined in three interaction scenarios. Each scenario corresponds to a different network arrangement that defines the type of data that is exchanged between users, the path that data follows during these exchanges and the roles adopted by users. The three interaction scenarios detailed below are called: *Drum Machine*, *Clone* and *Solar System*.

These scenarios were designed to showcase different levels of intensity in the network's influence and channels for mutual interaction between players. In the *Drum Machine* scenario, no mutual interaction happens between players as they only share an underlying rhythmic structure imposed by the network and cannot communicate information to each other. In the *Clone* scenario, mutual interaction only exists in a delayed manner as the sound recorded by a player before playing only influences the other player during the performance. In this case, communications channels exist but are only open before performance. Mutual interaction is at its strongest in the *Solar System* scenario, where communication channels are permanently open during performance, as the player in the *sun* role has an active influence on the sound of the others.

*Drum Machine*. In this scenario, all users share a common musical clock. Users can record a *model* sound and choose a *generator* sound among a soundbank. They can also use sliders to change some synthesis parameters (cf. Section 3.3). A loop section is defined on the *model* sound. The loop section can be moved over the *model* sound signal. The length of the loop section on the *model* signal is restricted to a rhythmic grid based on the shared clock. The result can be seen as a sort of distributed drum machine. See Fig. 2 for a diagram showing the communication channels in this scenario.

*Clone*. At the start of this scenario, users are asked to record a sound using their microphone. This sound will then be sent to another user to act as their *generator* sound. When playing, users will not be able to choose another *generator* sound. Hence, each user must learn to play with the voice of another user. In this scenario, users can record a *model* sound, define a loop section on the *model* sound and use sliders to change some synthesis parameters. See Fig. 3 for a diagram showing the communication channels in this scenario.

*Solar System*. Unlike in other scenarios, users are in an asymmetric configuration. One of them (called the *Sun*) is the only one able to record a *model* sound. The analysis data from this *model* sound is then simultaneously sent to all other users (called *Satellites*) to control their sound synthesis. On their end, Satellites may select a *generator* sound from a soundbank and act on various synthesis parameters. Hence, the same *model* sound recorded by the *Sun* is simultaneously reinterpreted by various *generator* sounds on the satellites. See Fig. 4 for a diagram showing the communication channels in this scenario.
<figure><img src="image_5.png" /><figcaption>Figure 2: Diagram of interaction and data communication in the *Drum Machine* scenario.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Figure 3: Diagram of interaction and data communication in the *Clone* scenario.</figcaption></figure>

## 3.3 Interface design

The interface underwent several iterations through testing and refinement. Particular attention was paid to limit its complexity by selecting carefully the number of interactive elements. This choice

was made in order to facilitate the familiarization and appropriation of the system in a limited timeframe and to foster the agentivity of the participants in a context of collective improvisation. Several modifications were made to the interface after a pilot study. This
<figure><img src="image_7.png" /><figcaption>Figure 4: Diagram of interaction and data communication in the *Clone* scenario.</figcaption></figure>

includes adding color panels, making important elements bigger and by having their placement more coherent with the intended way to use the interface.

The interface may differ slightly according to the different scenarios of the system. Figure 5 shows the interface in the *Drum Machine* scenario. Interfaces of the other scenarios are shown in the appendix. Apart from these slight differences, the interface generally comprises the following elements:

* A recording area from which the user can trigger the recording with the microphone, visualize the waveform of the recorded sound and trigger the use of this recording as their *model* sound (top left area in the figure).

* An area dedicated to the *generator* sound with a menu allowing the user to select a sound file among a soundbank, visualize its waveform and play it back (top right area in the figure).

* The main panel (at the center of the figure) shows the waveform of the *model* currently in use. The user can select a section to loop using the mouse. The selected loop can be of any length, or constrained by a time grid. The display of the *model* sound waveform was chosen to offer a balance between giving some information on the resulting sound and an invitation to explore and play. Indeed, while the waveform reflects the sound level of each section of the *model* sound and thus of the synthesized result, the audio engine also takes into account other dimensions of the sound, which means that the generated result cannot be fully anticipated, thus encouraging the user to explore.

* Finally, at the bottom of the interface, four sliders allow the user to modify various synthesis parameters: volume, pitch,

period and duration of sound grains. Access to these few parameters, which are common to most granular synthesis-based instruments, enables a greater variety of instrumental play and opens up important possibilities for complementarity and dialogue between users.

# 4 USER STUDY

## 4.1 Participants

We recruited 9 participants (aged 20 to 40) via personal and professional network. Participants were grouped in groups of 3 for a workshop session depending on the moment they were available. They had no previous experience of playing with each other. We specifically sought participants with a practice in musical improvisation and with basic knowledge of electronic music instruments (i.e. having already used a Digital Audio Workstation and/or hardware synthesizers and familiarity with the vocabulary and concepts of digital audio synthesis), to ensure that the learning time of the interface would not take too long and that they would be comfortable to improvise with the other participants. Participants were not remunerated but were given snacks and drinks during the experiment.

## 4.2 Setup

Groups of participants were invited in our laboratory in a room where the experimental setup was installed.

The experimental setup consists of multiple stations (one for each participant) set up around a table. Each workstation is comprised of :
<figure><img src="image_8.png" /><figcaption>Figure 5: Interface of Simone in the *Drum Machine* scenario. Other scenarios' interfaces may differ and are adapted to each scenario's specific task</figcaption></figure>

* the participant's computer (laptop) with a web browser connected to Simone,

* a Shure SM58 microphone mounted on a stand,

* an audio interface to connect the microphone to the participant's computer,

* a pair of loudspeakers (Creative Inspire T10) with one turned towards the center of the table and the other one turned toward the participant's workstation to provide audio feedback,

* a pair of closed headphones (used only in the first testing phase of the workshop (cf. Section 4.3).

The main experimenter's computer was used to create a local network and to launch the application's server. It was also used to send messages to participants whenever necessary during the improvisations using a dedicated web page. A camera and an audio recorder were installed to record the whole workshop.

The soundbank used by participants in the workshop included instrumental sounds (a piano piece from Bach, a vocal piece from Monteverdi), a drum loop, 2 vocal sounds (one of a person speaking and one of a person whispering), 2 field recordings of percussion made by the first author, field recordings of insects and birds, and 2 files of electroacoustic music samples.

## 4.3 Procedure

Before starting the workshop, participants are given an information notice detailing the context, goals and the experimental procedure. They are also asked to sign a consent form to allow us to record the audio and video of the workshop.

After that, the main experimenter explains the general structure of the workshop and introduces Simone and more especially the concept of audio mosaicing to the participants. Then, participants are brought to a solo version of Simone. During 10 minutes they can freely use this interface using headphones to familiarize themselves

with the controls and the way audio mosaicing works. This first step also aims at allowing them to acquire a basic sonic vocabulary.

After these 10 minutes of discovery of the interface, the workshop consists of three sessions corresponding to each of the interaction scenarios described in section 3.2¹. For each of these scenarios participants are asked to perform a collective improvisation for 7 to 8 minutes. Following the improvisation, the main experimenter engages a group discussion to record their immediate impression by asking “Do you have any remarks? What is your immediate reaction?”. After these three sessions, the main experimenter starts a semi-structured group interview of around 30 minutes with the participants. Questions in this final interview focus on asking participants to detail how they used the instruments and which strategies they employed during the improvisations, especially in relation to the collective and network aspects of the sessions :

* How did you use the interface? Do you have any remarks about the interface and the system in general?

* From a musical point of view, can you describe what you did, the strategies you employed?

* What do you think of the musical result you produced?

* What did you think of the collective and networked aspects of the system compared to more traditional individual musical practice?

We decided to perform group interviews rather than individual interviews as we were interested in capturing how participants perceived interpersonal dynamics within the workshop. Moreover, group discussions allows participants to pick up on other participants' comments and impressions thus highlighting converging and diverging opinions and points of view and providing insight on social relationships within the group [17].

<footnote n="1">¹Two of the groups performed the session in the order 1) *Drum Machine* 2) *Clone 3)* *Solar System* and one of the group in the order 1) *Clone 2)* *Solar System 3)* *Drum Machine*</footnote>
After this final discussion, participants are asked for final re-
marks and thanked for their participation. In total the workshop
lasts for approximately 2 hours.

We recorded audio and video using a camera and audio recorder. Recordings of the interviews were automatically transcribed and transcriptions were corrected by hand. Video excerpts of the sessions can be seen at the following address: https://www.youtube.com/ playlist?list=PLt5gV5YpSJ0yrdYUodXI6Q_4SRfSFWb3y

<figure><img src="image_9.png" /><figcaption>Figure 6: A picture from one of the workshop sessions show-
ing the experimental setup.</figcaption></figure>

5 RESULTS

5.1 Method

In order to identify shared themes across the subjective experience
of our participants, we analyzed our interview data using reflexive
Thematic Analysis (TA) as described by Braun and Clarke [45]. TA
is a flexible method for analyzing qualitative data that consists, after
familiarization with the data, in a first step of coding (i.e. assigning
a “code”, a short label, to sections of the data) and a second step
of theme development (i.e. identifying theme running across the
codes). Our approach was inductive, meaning that codes were de-
veloped from the data itself and not from a predetermined coding
scheme. We followed a critical realist framework, assuming an in-
dependent reality but acknowledging that this reality is not directly
accessible due to the subjective and located nature of participants’
experience and discourse in regard with their personal background
and the broader socio-cultural context. In addition, reflexive TA
specifically acknowledges the subjectivity of the coding and the
interpretative task by the researchers.

The process of coding, using both semantic and latent codes, was
undertaken independently by the first two authors. These codes
were then regrouped into proto-themes. Finally, we compared our
proto-themes and discussed together to converge toward three main
themes: (1) Participants’ relationship to constraints and freedom
 subsections: (2) their description of the process of familiarization
and learning of the instrument (section 5.3), and (3) their description
of group dynamics with regard to the networked nature of the
instrument (section 5.4).

In the following, participants are referred to as P1 to P9. The
three groups were composed of : P1 to P3, P4 to P6 and P7 to P9.

5.2 Theme 1: The relationship to constraints
and freedom

Interviews with participants revealed a complex and ambiguous
relationship to their (often contradictory) perception of constraints
and freedom during the experiment. Most participants reported on
the various types of constraints they perceived during the work-
shops. These constraints were of different kinds. Some of them
were built-in the instrument's interface, some of them came from
how sound synthesis works and some others were consequences
of the different scenario's explicit constraints.

Regarding *scenario constraints*, some participants interestingly
noted that the limitations did not restrain their agency. For example,
when commenting on the *Solar System* session, P9 says that “there
was still enough parameters to focus on”. Similarly, after the same
scenario, P5 commented that they “thought it would be harder to
make different stuff because we have the same target so but in fact
the sources are very different so if we select different sources then
we are... it’s easier to complement each other I would say”.

This comment points toward the fact that constraints were actually perceived as helpful. A limited set of parameters meant “less to think of, in a good way” (P4) and would reduce the overall cognitive load of the interface and guide exploration and understanding of the instrument’s possibilities. This fact is highlighted by comments from P1: “with fewer parameters, we at least know what they do”, P4: “I also like the limitations. I think it’s easier to explore in a way and not be too focused on the possibilities of the interface” and P5: “in this case having like the *model* [sound] fixed makes you really think about what the *generator* [sounds] are, how to use them”.

Constraints also proved to be fruitful for collaboration between
participants: a reduced set of parameters increased P1's mutual
attention to the group's actions and scenarios' constraints forced
P4 to think about collaboration and to "figure things out together".
On a musical level, scenarios' constraints also increased feelings of
synchronization (P3, P7).

However these constraints were sometimes also perceived nega-
tively. For example, in the *Drum Machine* scenario, P5 reports that
they felt the rhythmic “grid was quite limiting” and that “the im-
position was too strong”. In the *Clone* scenario, P2 mentioned that
they felt “stuck” because of the *generator* sound they were assigned
and that “it was quite frustrating not to be able to have a sound
that I liked but that also contributed to something [...] that was
happening.” Finally, in the *Solar System* scenario, P3 (who assumed
the *sun* role) felt that they missed the ability to send different data
to each of the *satellite* players.

Regarding the *interface*, many comments from the participants
suggest that they perceived the instrument as rich and complex,
offering a “lot of possibilities” (P6), “a lot of choices” to make (P3) or
“quite of lot of things to do” (P3) when playing. This richness of the
interface is reflected in the rich variety of sound the instrument is
capable of producing or in the flexibility it offers to create different
effects with a rather low number of parameters. For instance, as
P4 noticed that the two other participants used the same *generator*
sound at some point, they remarked “I think it was still quite rich.
Like there was still difference to it”.
However, this complexity was not always perceived as positive. Some participants saw the instrument as being too complex or offering too many parameters to manipulate, even seeing this complexity as a “risk” (P6). This complexity would keep players in a permanent state of exploration and testing that would prevent them from focusing on the task of collective improvisation (P1, P5).

It is worth noting that what is perceived as a constraint is not absolute but sometimes heavily dependent on the participant's own experience and background. This fact is most visible when P2 and P3 addressed the topic of rhythm within the *Drum Machine* scenario. The rhythmic grid constraint was felt as enjoyable by P2 as they reported that they could “feel a pulse”. We even noticed that this participant's foot was tapping along the beat during the session. They perceived this constraint as satisfying, linking it to their own musical practice: “maybe it's because I'm a percussionist, I liked it”. On the other hand, P3 did not perceive the “rhythmical impact” of this constraint as the micro-temporal events of granular synthesis went against their conception of musical rhythm as “a hierarchy of representation” of “pulse, rhythm, tempo”.

This very subjective reception of freedom and constraints is also reflected in the way some participants implemented personal strategies either by working around constraints they disliked or by self-imposing constraints. For instance, P5 and P9 described trying to find ways to go around the inherent rhythmical nature of loops in Simone to try to “do something more continuous or different” (P5) while P3 reported that they chose to focus only on “two or three *generator* sounds” (among 12) to avoid spending too much time exploring the possibilities of the whole soundbank.

To summarize, all these comments map out a fairly complex and ambiguous relationship to constraints within Simone. For participants, full satisfaction with the instrument and the conduct of collective music endeavors requires the design of, as P5 describes, “a nice balance between freedom and limitations”, something rendered arduous by the fact that this relation to constraints is very much subjective.

## 5.3 Theme 2: Learning and taming the instrument

Interviews revealed that over the course of the workshop participants had a sense of learning how to control an instrument that was often perceived at first as hard to control. This conscious process of learning was highlighted in the interviews:

> No, there was definitely like a learning [...] So it's more like ways of playing evolve over time because you try new stuff and suddenly you have a grip on what you're doing. So ok, this makes that so I'm going to do it again or doing slightly differently. (P6)

Moreover, getting this “grip” on the instrument proved to be a necessary condition before participants started collaborating. For example, P6 reported that “at some point I remember it was towards the end of a performance I was kind of, felt like, okay I kind of get what is happening so now let’s try to interact” (P6). This requirement of a certain degree of appropriation as a condition for collaboration is described by several participants (P1, P3, P6)

who originally engaged in a phase of testing and exploration, but quickly realized that this prevented them from engaging with other players:

> I had so much choice of *generator* sound [...] I think I didn't take enough time to settle on one sound and think ok now let's choose this and play with finer parameters and listen to what's going on with the other [participants]. (P1)

At first, participants indeed described Simone as unpredictable or reacting in unsuspected ways. For example, P1 reported it as “difficult to anticipate”, and P5 described it as “stochastic, chaotic” and with the ability to “change completely the environment if you mess with [it]”. It appears that this feeling of unpredictability has multiple roots. First, some participants had difficulties gauging their influence on the instrument’s output (P1, P9): “What I recorded... to me, it didn’t seem to have much effect on what I was making” (P9). Second, some participants felt that they could not rely on familiar combinations of parameters as two very close states could yield vastly different results : “I’d change things and go back to a previous state and it wasn’t the same. I felt like I couldn’t repeat it.” (P1).

To overcome these problems, participants elaborated different strategies for creating a vocabulary around the instrument. This is first reflected in their description of how they approached the instrument to try to understand how it works. While P5 and P7 described taking a more intuitive/inductive approach: “At first [...] I was kind of trying to get a feel of it [...] more like poking around and thinking “ok this does this, this does that”. Not asking myself like, “what does it mean technically?”” (P7), P4 reported on the contrary that “there is something about the interface that makes me want to approach it in a cognitive way” and that they tried to understand “exactly what’s happening” from a technical standpoint.

From another perspective, it seems that participants’ process of making sense of the instrument happened through the prism of their own musical background and preconceptions. This is reflected for example in their reliance on traditional music concepts such as tonal harmony and rhythm when describing their approach but also as they compared Simone to traditional instrumental practice. While some participants’ familiarity with granular synthesis (P9) or with working with sound collage (P7) seemed to ease their learning curve, others were startled by the way Simone would work very differently from a traditional instrument: “There’s a way of triggering sound that’s not a visible gesture like tapping on an instrument and it comes out. It’s more based on the dynamics of the waveform, on granularity. (P3)”

To summarize, all these comments highlight that participants implemented different strategies to overcome what appeared at first to be unpredictable or complex features of the instrument and that they considered this learning phase as a condition for collaborating on the improvisation.

## 5.4 Theme 3: Networked group dynamic

Participants described the strategies they employed to play collectively with the other players. While this collaboration was sometimes fragile and hard to establish due to various obstacles, it was nonetheless perceived as satisfying. Participants’ discourse focused
on human to human interaction but also on their specific relation-
ship to the network that varied greatly depending on the scenario.

Although musical improvisation generally does not prescribe
any specific type of interaction [39], participants' main strategy
during the workshops seemed to be to complement each other's
sounds (rather than disrupting other players' actions or simply
playing independently from the others). For instance, as P4 was
about to record their sound previous to the *Clone* sessions, they
made the remark that they were influenced by what P5 recorded
just before: "I'm thinking now of not adding vocals, because [P5]
did". This complementarity was also present when participants
were playing :

At the end of the third session we were more into
very environmental sounds. I mean, there were bird
sounds. And then I thought, ok, I'll try to go in that
direction too, I'll try to make sounds that are very...
Yes more towards noises or things that are evocative
of sounds that are a bit more natural. (P7)

This matter of complimenting others’ sound was mostly influ-
ential on the choice of *generator* sound participants would choose,
but they also sought out to complement musical structure at the
micro level: “Sometimes some loops were coming back in a way. So
I tried to adjust and say, you want to do loops, so I’m going to try
to jump in and see whether I can add to it” (P6).

At the macro level, participants seemed concerned with the build-
ing of a mutual construction which was made easier by working
with “gradual” (P5) changes. Participants’ perception of the group
dynamic is aligned with a common view of free improvised music
as a mutual construction, perpetually moving, in danger of col-
lapsing at any moment but whose collapse is essential to uphold a
sense of creativity. But because participants’ were also in a learning
process regarding Simone, they favored a cautious approach where
disturbing the current state was seen as creatively destructive more
than productive:

**P4:** It would be interesting to see if we have the same idea on which moments were good surprises. But it's very fleeting and it's like suddenly happening and then suddenly it's gone because someone did something.

**P6:** Or sometimes it's nice for a while and then it becomes boring. [...] There's this difficulty of finding a zone where it seems to work and then it doesn't seem to work anymore and you have to move. I mean it's what free improvisation is about. But here because we're not very familiar with the instrument or the thing it's even harder I would say.

Yet, this challenge that necessitates quick adaptation was deemed
interesting by other participants:

**P7 (sun):** I was afraid to go in directions that would not be satisfying to them you see. Or changing a lot of stuff. In fact it can be disturbing. You're trying to build something, for example and I'm going to modify... bring a bit of chaos in that

**P8 (satellite):** But you have to readjust. And that's interesting. As you say, it makes you change your

plans. Sometimes, you make a little mechanism for 30,
40 seconds, thinking “I’m going to go towards here”,
and then in fact, [the *sun* player] shortens our loop,
you see, and as a result, we no longer have access to
the same... You have to readjust pretty quickly. I think
it’s interesting, actually.

This cautious approach was also reflected in the way participants
would manage volume during the workshops, often playing very
low leading to a prisoner's dilemma situation where everyone is
waiting for the others to be more daring. Short interviews between
sessions were also the place where the group would discuss read-
justments to be made and group strategies to follow: "Maybe we
should all just put the volume really high" (P4).

Participants also reported on several elements that were an ob-
stacle to group dynamics and collaboration. This includes the fact
that the interface demands too much focus on the screen hence
preventing interpersonal gaze which could be useful to transmit
cues (P1, P2, P4, P6, P7), the difficulty to hear other participants due
to loudspeakers disposition creating a "distance" and a "separation"
(P9) between players (P1, P2, P3, P6, P8, P9), the difficulty to single
out contributions because of the homogeneity between produced
sound (P1, P4) or the process of recording which was perceived as
as embarrassing because it disrupted the shared sonic space (P1).

Underlying all collective interaction in Simone is the network.
But depending on the scenario, it was not always perceived. From
the comments gathered, it appeared that the participants were
mostly aware of the presence and actions of the network in the
*Solar System* scenario in which an action from a participant had an
influence on another participant was directly perceptible:

> It is in the [solar system scenario] that the network aspect appears clearly. It was the first time I had the impression that... a real feeling of synchronization with the others. [...] There is an obvious action from one computer to the other. (P1)

For the other scenarios where players cannot send data to each
other, the network's action was barely noticed or was seen as too
"simple" (P5) or as "primitive" (P3) which made some participants
wish for more interactivity between players in the form of increased
distribution of parameters:

> Maybe in [the *Drum Machine*] case giving... like mul-
tiplication, loop windows divisions, giving more dis-
tributed controls on rhythm may be interesting. Even
giving subdivisions or beat modifications. It could
change a lot. (P3)

The fact of distributing control of parameters not only increased
awareness of the network but also awareness of the other players,
giving a more acute sense of group interactions:

> Because I'm wondering whether there's really an ac-
tion that's just been done by the other person that's
affecting my sound or not. [...] In this interaction, I
have the impression that I'm really thinking in terms
of people's actions, and that I'm wondering what ac-
tions are the other people in this network producing?
There's a point where it goes a bit beyond music, [...] it's something where there's really a question of network and... And inter-action between... the players that I find quite strong. (P1)

In some extreme cases, the interaction agency enabled through the network could also be perceived as unbalanced. For instance in the *Solar System* scenario, where the *sun* player can decide whether to mute the *satellite* players, some satellite players felt such action as “brutal” (P7) or even “infantilizing” (P9). Therefore, any action in the network can be seen either as positive or negative, and careful actions are required by all players to create a balanced and creative environment. This represents one of the challenges of such an approach. Globally, despite the few cases we just reported, participants reported a rather collaborative and constructive interaction between themselves.

# 6 DISCUSSION

## 6.1 Shared agencies in collective musical interaction

In this paper we have always referred to Simone as “an instrument”, using the singular, which of course can raise the question of whether Simone constitutes a single instrument played by multiple players, or multiple separate instruments connected to each other. In his article on “multi-user instruments” [23], Jordà identifies inter-dependence as one of the main properties that characterizes such an instrument, arguing that “if no mutual interaction is allowed, the concept of multi-user instrument is definitely debatable”. Hence, the question becomes how to define and design such mutual interaction, which Weinberg consider achievable (in what he calls Interconnected Musical Networks) “only by constructing electronic (or mechanical) communication channels among players”, in which case “participants [can] take an active role in determining and influencing, not only their own musical output, but also their peers” [50].

At first, such a position seems to be confirmed by the fact that this perception of mutual interaction over the instrument was also shared by our participants as they felt the presence of the network more strongly in the *Solar System* scenario while it was felt as weaker in the other scenarios. However we believe that Simone still qualifies as a single instrument even in cases where no direct connections are built between players (like in the *Drum Machine* scenario), as they are still connected over a shared structure (e.g. rhythmical grid) that has a strong influence on players. Indeed, this feeling of interdependency appearing from a shared structure is present in multiple musical traditions, an example of which is the Indonesian Gamelan often considered to be a single instrument played by many persons. We believe that an interesting avenue for developing further such an idea would be to provide the network with an even stronger role to the point that users of the instrument would perceive it as having its own agency.

Another interesting question lies in the way agency over different aspects of sound, or of musical parameters, can be established in such a collective interaction. This idea has already been identified by Jordà who describes the case of two persons performing

on the same piano with one player playing the keyboard and another playing the pedals (thus affecting the timbre of the resulting sound) [23]. In many examples of multi-user instruments, like *Voice Networks* [51] or *88 fingers* [42], the design of the system gives an equal role over all aspects of the instrument to the players. In Simone, and in particular in the *Solar System* scenario, players are only able to control certain dimensions of sound synthesis, while being deprived of control on other dimensions and thus relying on other player’s contribution (cf. Figure 7). Interestingly, such asymmetry was identified by one of our participants (P1, see section 5.4) as a concept that strengthened the feeling of interaction between players over a same distributed instrument. Such hierarchies and asymmetry need however to be carefully designed and thought of, as our results also show that losing control on some aspects of sound can lead to confusion.

<figure><img src="image_10.png" /><figcaption>**Figure 7:** Two ways of designing the way of sharing control of parameters in a distributed instrument. On the left, each player has control on all dimensions of sound. On the right, each player can only control one dimension of sound, relying on other player's contribution to act on the other ones.</figcaption></figure>

## 6.2 Designing constraints and instrumental agency

From the beginning, Simone has been designed towards what we called “expert users”, defined as users familiar with digital music instruments and software. To that end, we decided to build a fully digital interface borrowing ideas from Digital Audio Stations (DAW) interfaces, with a limited number of parameters and with a straightforward mapping between available input/parameters and their effects (cf Fig. 8). For example, granular parameters in the interface like “detune” or “grain duration” are directly mapped to said detuning or duration of sonic grain, making it self-explanatory for any user familiar with granular synthesis.

Nonetheless, the different learning paths we observed during our experiments led us to reconsider the category of “expert user”, as it appears difficult to gather users with vastly different baggage in a single category. Indeed, depending on their practice and experience, users brought varying expectations and different ways to make sense of the behavior of the technological artifact, which made us reflect on our initial assumptions and beliefs on the relative neutrality of some of our design choices.

Regarding design choices, our participants described the various constraints of the system as helpful for reducing the cognitive load
<figure><img src="image_11.png" /><figcaption>**Figure 8:** The interface of Granulator III by Robert Henke, a fairly popular granular synthesizer plugin for Ableton Live. Notice the similarity with the Simone interface: the display of the waveform, some of the parameters available (grain size, transpose)</figcaption></figure>

of the interface and for guiding the process of familiarization and understanding of the instrument. The role of constraints in early stages of familiarization with a digital instrument has already been identified in earlier works with Magnusson [28] stating that “the main bulk of the time spent in learning the instrument involves building a habituated mental model of its constraints” and with Gurevich et al. [20] noting that the development of personal style “emerges both as a result of constraint [...] as well as in spite of constraint”. As in our study, the latter also observes that users’ “interpretation” of constraints can be heavily dependent on context and users’ background.

While these works focus on the case of individual instruments, our results also show that in a collective instrument, constraints are helpful to guide collective interaction. The specificity of Simone in that domain lies in the fact that beyond the instrument's inner sonic constraints, another layer of constraints is created by the interaction scenarios' rules.

Magnusson describes digital music instruments as “epistemic tools”, noting that the act of designing such a system “entails the encapsulation of a specific musical outlook”[27]. Simone makes no exception and carries values of its designers as musicians, purposely avoiding the use of concepts from western music theory such as pitch or time signatures in favor of a more experimental approach. We may further state that Simone was in part created by us not from a top-down approach but with an experimental approach as musicians and users ourselves. The design process was “organic”, borrowing elements from musical and technical influences we mentioned, testing the instrument at each new version and sometimes renouncing to have a total control on all aspects of the produced sound.

There has been much discussion in the design and NIME community digital music systems having their own agency [6, 7], often drawing on Actor Network Theory [25] and Cybernetics [52], and leading for example to the development of actual instruments such as Davis’ *Feral Cello* that seeks to “actively challenge notions of instrumental mastery and ‘absolute control’” [13]. In fact, our design process might evoke the practice of “hacking” that is commonly found in the world of improvised music. In an ethnographic study on improvisers building-up their own instrumental devices [8], Canonne describes a practice that embraces devices that are inherently unpredictable and prone to accidents out of the control of its user. The fact that these instruments possess their own agency as

he says, “allows the improviser to discover new uses” during the time of the performance.

Hence, while some unpredictable aspects of mosaicing synthesis in Simone has startled participants and as Magnusson argues, “where the digital instruments exhibit any chaotic or entropical behaviour, it tends to be due to a failure in design, a bug in the code or loose wiring in the hardware” [27], we think of it as an integral part of the instrument and as well-suited to the task of improvisation Simone was intended for. Playing with Simone collectively is therefore intended not as a task of building a mutual construction with a tool that bends to the will of its users, but more as trying to collectively tame a system with its own proper agency and to accept its serendipitous nature. The collective nature of Simone therefore does not reside only in the time of performance but also in between sessions when users may exchange tips and devise strategies to work with the system.

## 6.3 Instrumentality and collective improvisation

The book *The Practice of Musical Improvisation* (TPoMI in what follows) by Bertrand Denzler and Jean-Luc Guionnet [14] provides a valuable account of the experience of collective improvisation from the point of view of improvisers. The way some of the comments found in these interviews echo comments from our participants and some of our observations allows us to reflect on some aspects of the design of Simone as an instrument for improvisation.

In the absence of a predetermined shared plan or referent to follow, one can wonder which elements drive musicians’ decision-making process and the temporal evolution of collective interaction in free improvisation. During our workshops, our participants described that they tried to complement the sound of other players but that these moments of coordination were sometimes disturbed by a player’s decision to go in another direction, a vision reminiscent of Borgo’s description of improvisation as a negotiation of freedoms and as “a forum in which to explore various cooperative and conflicting interactive strategies” [4]. This dialectical process of construction and destruction as the creative core of free improvisation [5, 10] put our participants in a state of permanent awareness to adapt to other player’s actions, as described in *TPoMI*: “When you’re playing, you’re fine-tuning all the time, you’re constantly adapting to different factors which more or less generate the content.” and “Sometimes, all of a sudden, there is a moment where it’s going over the edge and falls into something totally different, and you need to be ready to go with that”

One of our participants’ commented that the distributed control of parameters in the *Solar System* scenario strengthened a sense of “inter-action” even suggesting that “it goes a bit beyond music”. This is in line with the recognition that such extra-musical relationship is often sought out by free improvisers in their musical practice:

> It's not only the sound. There's also the presence, the state of mind of the person, things that essentially you discover before playing, in a discussion, in a social relationship with the person. So it's a whole. In the
end what I’m looking for isn’t music, but rather a
particular space for exchange. (TPoMI)

Perhaps more than a matter of interaction, one improviser in *TPoMI* mentions that “when I play with other musicians, lots of barriers fall. It’s no longer me and them, but rather a kind of unity that forms, that’s part of the listening”. In Simone this feeling of unity is perhaps reinforced by the fact that participants use a similar interface, synthesizer and share the same soundbank, giving more cohesion to the overall sound produced and a better understanding of others’ actions: “because we all have the same controls, the same parameters, I know what you have to do. It’s not like you’re playing the trumpet or something and I don’t know exactly what you’re doing. So I know he can do this, he can do that and it’s the same things I can do. [...] It’s easier to understand what they are doing” (P9). However, several comments from our participants suggest that this feeling of unity could have been improved by providing more visual feedback on the actions of other players and network communication between players, by improving the technical setup to give the impression of a shared sonic space instead of localized loudspeakers and by providing a way to use Simone with a tangible interface.

7 CONCLUSION AND PERSPECTIVES

In this paper, we employed a research through design approach to
study the design and appropriation of Simone, a distributed musical
instrument for collective improvisation.

Our contributions are twofold: First, we presented the design and implementation of Simone whose originality lies in its implementation of different interaction scenarios that define the way users are interconnected through the network. Second, we studied the process of appropriation of the system by expert users. To that end, we organized workshops where groups of participants were asked to improvise collectively with Simone and where we collected qualitative data through semi-structured group interviews. These data allowed us to reflect both on the design of Simone as well as on the forms of learning paths and of collective improvised interaction that occurred during the workshops.

Our results suggest that the process of appropriation is guided
by a complex perception of the constraints of the instrument and
is strongly dependent on participants’ musical background. It also
shows that after this step of familiarization, participants were able to
interact collectively to build a coherent musical discourse and that
these interactions were influenced by the networked connections
between participants and the different interaction scenarios within
Simone.

For this initial design step of Simone, most decisions regarding
the instrument design were made prior to user appropriation. In
future works, considering with Canonne that an interesting aspect
of free improvised music practices lies in the process of coevolution
between the improvisers’ practice and their instruments in the
form of instrument augmentation and *bricolage* [9], we will focus
on observing how design decisions of such a distributed system
can be left to its users and how the system can evolve over a longer
period of time and use.

ACKNOWLEDGMENTS

The work described in this article has received support from the
DOTS research project funded by the French National Research
Agency (ANR-22-CE33-0013-01).

REFERENCES

[1] [n. d.]. WebAudio API Specification. https://www.w3.org/TR/webaudio/.

[2] Derek Bailey. 1993. *Improvisation: Its Nature and Practice in Music*. Da Capo Press, New York.

[3] Frederic Bevilacqua, Benjamin Matuszewski, Garth Paine, and Norbert Schnell. 2021. On Designing, Composing and Performing Networked Collective Interactions. *Organised Sound* 26, 3 (Dec. 2021), 333–339. https://doi.org/10.1017/S135577182100042X

[4] David Borgo. 2002. Negotiating Freedom: Values and Practices in Contemporary Improvised Music. *Black Music Research Journal* 22, 2 (2002), 165. https://doi.org/10.2307/1519955 jstor:1519955

[5] David Borgo. 2005. *Sync or Swarm: Improvising Music in a Complex Age*. Continuum, New York.

[6] David Borgo and Jeff Kaiser. 2010. Configurin(g) KaiBorg: Interactivity, Ideology, and Agency in Electro-Acoustic Improvised Music. In *Proceedings of the International Conference Beyond the Centres: Musical Avant-Gardes Since 1950*. Thessaloniki, Greece.

[7] Oliver Bown, Alice Eldridge, and Jon McCormack. 2009. Understanding Interaction in Contemporary Digital Music: From Instruments to Behavioural Objects. *Organised Sound* 14, 2 (Aug. 2009), 188–196. https://doi.org/10.1017/S1355771809000296

[8] Clément Canonne. 2019. Élaborer Son Dispositif d'improvisation : Hacking et Lutherie Dans Les Pratiques de l'improvisation Libre. *Volume !* 16 : 1 (Dec. 2019), 61–79. https://doi.org/10.4000/volume.7266

[9] Clément Canonne. 2021. *La Lutherie Des Improvisateurs*. [Unpublished manuscript].

[10] Clément Canonne and Nicolas B Garnier. 2012. Cognition and Segmentation In Collective Free Improvisation: An Exploratory Study. In *International Conference on Music Perception and Cognition*. Unpublished, Thessaloniki, Greece. https://doi.org/10.13140/2.1.3534.9445

[11] Clément Canonne, Roméo Monteiro, and Joris Rühl. 2011. L'EMUPO: Une Interface Logicielle Pour l'improvisation Collective. In *Journées d'Informatique Musicale (JIM 2011)*. Saint-Etienne, France.

[12] Nick Collins. 2010. *Introduction to Computer Music*. John Wiley & Sons, Hoboken.

[13] Tom Davis. 2017. The Feral Cello: A Philosophically Informed Approach to an Actuated Instrument. In *International Conference on New Interfaces for Musical Expression (NIME 2017)*. Copenhagen, Denmark.

[14] Bertrand Denzler and Jean-Luc Guionnet (Eds.). 2020. *The Practice of Musical Improvisation: Dialogues with Contemporary Musical Improvisers* (1st. ed.). Bloomsbury Academic, New York.

[15] Alain Findeli. 2012. Searching for Design Research Questions: Some Conceptual Clarifications. In *Mapping Design Research*, Simon Grand (Ed.). Birkhäuser, Basel.

[16] Jason Freeman, Kristjan Varnik, C. Ramakrishnan, Max Neuhaus, Phil Burk, and David Birchfield. 2005. Auracle: A Voice-Controlled, Networked Sound Instrument. *Organised Sound* 10, 3 (Dec. 2005), 221–231. https://doi.org/10.1017/S1355771805000968

[17] James H. Frey and Andrea Fontana. 1991. The Group Interview in Social Research. *The Social Science Journal* 28, 2 (June 1991), 175–187. https://doi.org/10.1016/0362-3319(91)90003-M

[18] William Gaver. 2012. What Should We Expect from Research through Design?. In *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems*. ACM, Austin Texas USA, 937–946. https://doi.org/10.1145/2207676.2208538

[19] Scot Gresham-Lancaster. 2017. A Personal Reminiscence on the Roots of Computer Network Music. *Leonardo Music Journal* 27 (Dec. 2017), 71–77. https://doi.org/10.1162/LMJ_a_01022

[20] Michael Gurevich, Adnan Marquez-Borbon, and Paul Stapleton. 2012. Playing with Constraints: Stylistic Variation with a Simple Electronic Instrument. *Computer Music Journal* 36, 1 (March 2012), 23–41. https://doi.org/10.1162/COMJ_a_00103

[21] William Hsu. 2005. Using Timbre in a Computer-Based Improvisation System. In *International Computer Music Conference (ICMC)*. Barcelona, Spain.

[22] Jordi Janer and Maarten de Boer. 2008. Extending Voice-Driven Synthesis to Audio Mosaicing. In *Sound and Music Computing Conference (SMC '08)*. Berlin, Germany.

[23] Sergi Jordà. 2005. Multi-User Instruments: Models, Examples And Promises. In *International Conference on New Interfaces for Musical Expression (NIME 2005)*. Zenodo, Vancouver, BC, Canada. https://doi.org/10.5281/ZENODO.1176760

[24] David Kim-Boyle. 2009. Network Musics: Play, Engagement and the Democratisation of Performance. *Contemporary Music Review* 28, 4-5 (Aug. 2009), 363–375. https://doi.org/10.1080/07494460903422198
[25] Bruno Latour. 1996. On Actor-Network Theory. A Few Clarifications, Plus More Than a Few Complications. *Soziale Welt* 47 (1996), 369–381.

[26] Eric C. Lemmon. 2019. Telematic Music vs. Networked Music: Distinguishing Between Cybernetic Aspirations and Technological Music-Making. *Journal of Network Music and Arts* 1, 1 (2019).

[27] Thor Magnusson. 2009. Of Epistemic Tools: Musical Instruments as Cognitive Extensions. *Organised Sound* 14, 2 (Aug. 2009), 168–176. https://doi.org/10.1017/S1355771809000272

[28] Thor Magnusson. 2010. Designing Constraints: Composing and Performing with Digital Musical Systems. *Computer Music Journal* 34, 4 (Dec. 2010), 62–73. https://doi.org/10.1162/COMJ_a_00026

[29] Benjamin Matuszewski. 2020. A Web-Based Framework for Distributed Music System Research and Creation. *Journal of the Audio Engineering Society* 68, 10 (Dec. 2020), 717–726. https://doi.org/10.17743/jaes.2020.0015

[30] Benjamin Matuszewski, Norbert Schnell, and Frederic Bevilacqua. 2019. Interaction Topologies in Mobile-Based Situated Networked Music Systems. *Wireless Communications and Mobile Computing* 2019 (March 2019), 1–9. https://doi.org/10.1155/2019/9142490

[31] Noam Mor, Lior Wolf, Adam Polyak, and Yaniv Taigman. 2018. A Universal Music Translation Network. (2018). https://doi.org/10.48550/ARXIV.1805.07848

[32] Meinard Müller. 2007. *Information Retrieval for Music and Motion*. Springer, New York.

[33] Pauline Oliveros, Sarah Weaver, Mark Dresser, Jefferson Pitcher, Jonas Braasch, and Chris Chafe. 2009. Telematic Music: Six Perspectives. *Leonardo Music Journal* 19 (Dec. 2009), 95–96. https://doi.org/10.1162/lmj.2009.19.95

[34] Garth Paine, Frédéric Bevilacqua, and Benjamin Matuszewski. 2021. Collective and Networked Sound Practices. *Organised Sound* 26, 3 (Dec. 2021), 303–304. https://doi.org/10.1017/S1355771821000388

[35] Johan Redström. 2021. Research through and through Design. *Artifact* 8, 1 (Dec. 2021), 16.1–16.19. https://doi.org/10.1386/art_00016_1

[36] Curtis Roads. 2004. *Microsound*. the MIT press, Cambridge (Mass.) London.

[37] Julian Rohrhuber. 2007. Network Music. In *The Cambridge Companion to Electronic Music* (1 ed.), Nick Collins and Julio d'Escrivan (Eds.). Cambridge University Press, 140–155. https://doi.org/10.1017/CCOL9780521868617.010

[38] Julian Rohrhuber, Alberto Campo, Renate Wieser, Jan-Kees van Kampen, Echo Ho, and Hannes Hözl. 2007. Purloined Letters and Distributed Persons. In *Music in the Global Village Conference*. Műcsarnok Budapest.

[39] Pierre Saint-Germier, Cédric Paternotte, and Clément Canonne. 2021. Joint Improvisation, Minimalism and Pluralism about Joint Action. *Journal of Social Ontology* 7, 1 (July 2021), 97–118. https://doi.org/10.1515/jso-2020-0068

[40] Matthew Sansom. 2001. Imaging Music: Abstract Expressionism and Free Improvisation. *Leonardo Music Journal* 11 (Dec. 2001), 29–34. https://doi.org/10.1162/09611201052780647

[41] Flávio Luiz Schiavoni, Pedro H. De Faria, and Jónatas Manzolli. 2019. Interaction and Collaboration in Computer Music Using Computer Networks: An UbiMus Perspective. *Journal of New Music Research* 48, 4 (Aug. 2019), 316–330. https://doi.org/10.1080/09298215.2019.1635626

[42] Norbert Schnell and Benjamin Matuszewski. 2017. 88 Fingers. In *Web Audio Conference (WAC '17)*. London, UK.

[43] Diemo Schwarz. 2006. Concatenative Sound Synthesis: The Early Years. *Journal of New Music Research* 35, 1 (March 2006), 3–22. https://doi.org/10.1080/09298210600696857

[44] Phil Stone. 2021. Non-Mathematical Musings on Information Theory and Networked Musical Practice. *Organised Sound* 26, 3 (Dec. 2021), 327–332. https://doi.org/10.1017/S1355771821000418

[45] Gareth Terry, Nikki Hayfield, Victoria Clarke, and Virginia Braun. 2017. *The-matic Analysis*. SAGE Publications Ltd, 55 City Road. https://doi.org/10.4135/9781526405555

[46] Daniel Trueman, Perry Cook, Scott Smallwood, and Ge Wang. 2006. PLoRk: The Princeton Laptop Orchestra, Year 1. In *International Computer Music Conference (ICMC '06)*. New Orleans LA USA.

[47] Luca Turchet, Carlo Fischione, Georg Essl, Damian Keller, and Mathieu Barthet. 2018. Internet of Musical Things: Vision and Challenges. *IEEE Access* 6 (2018), 61994–62017. https://doi.org/10.1109/ACCESS.2018.2872625

[48] Maarten Van Steen and Andrew S. Tanenbaum. 2016. A Brief Introduction to Distributed Systems. *Computing* 98, 10 (Oct. 2016), 967–1009. https://doi.org/10.1007/s00607-016-0508-7

[49] Ge Wang, Georg Essl, and Henri Penttinen. 2008. Do Mobile Phones Dream of Electric Orchestras?. In *International Computer Music Conference (ICMC '08)*. Belfast, Ireland, 8.

[50] Gil Weinberg. 2005. Interconnected Musical Networks: Toward a Theoretical Framework. *Computer Music Journal* 29, 2 (2005), 23–39. jstor:3681711

[51] Gil Weinberg. 2005. Voice Networks: The Human Voice as a Creative Medium for Musical Collaboration. *Leonardo Music Journal* 15 (Dec. 2005), 23–26. https://doi.org/10.1162/lmj.2005.15.1.23

[52] Norbert Wiener. 1950. *The Human Use of Human Beings*. Houghton Mifflin.

[53] Victor Zappi and Andrew P McPherson. 2014. Dimensionality and Appropriation in Digital Musical Instrument Design. In *International Conference on New Interfaces for Musical Expression (NIME '14)*. London, UK.

[54] Aymeric Zils and François Pachet. 2001. Musical Mosaicing. In *COST G-6 Conference on Digital Audio Effects (DAFX-01)*. Limerick, Ireland.

[55] John Zimmerman and Jodi Forlizzi. 2008. The Role of Design Artifacts in Design Theory Construction. *Artifact* 2, 1 (April 2008), 41–45. https://doi.org/10.1080/17493460802276893

A INTERFACE FOR EACH SCENARIO
<figure><img src="image_12.png" /><figcaption>Figure 9: Before the *Clone* scenario users are brought to this interface to record a sound that will be sent to another user to become their *generator* sound.</figcaption></figure>

<figure><img src="image_13.png" /><figcaption>Figure 10: Interface of Simone in the *Clone* scenario. Compared to the *Drum Machine* scenario, user's cannot choose the *generator* sound from the soundbank (it is assigned to them at the start) and loops are no longer restricted to fixed length.</figcaption></figure>
<figure><img src="image_14.png" /><figcaption>Figure 11: Interface of Simone in the *Solar System* scenario for the *sun* player. In this role, controls are restricted to recording a *model* sound and starting/stopping synthesis of the *satellites*.</figcaption></figure>

<figure><img src="image_15.png" /><figcaption>Figure 12: Interface of Simone in the *Solar System* scenario for a *satellite* player. In this role, controls are restricted to choosing a *generator* sound among a *soundbank* and changing synthesis parameters.</figcaption></figure>