Aliénor Golvet

Louise Goupil

Pierre Saint-Germier

Benjamin Matuszewski

Gérard Assayag

Jérôme Nika

Clément Canonne
email: clementcanonne@hotmail.com

With, against, or without? Familiarity and co-presence increase interactional dissensus and relational plasticity in freely improvising duos

Keywords: improvisation, interactions, group creativity, co-presence, familiarity

Agents engaged in creative joint actions might need to find a balance between the demands of doing something collectively, by adopting congruent and interacting behaviors, and the goal of delivering a creative output, which can eventually benefit from disagreements and autonomous behaviors. Here, we investigate this idea in the context of collective free improvisation -a paradigmatic example of group creativity in which musicians aim at creating music that is as complex and unprecedented as possible without relying on predefined plans or individual roles.

Controlling for both the familiarity between the musicians and their physical co-presence, duos of improvisers were asked to freely improvise together and to individually annotate their performances with a digital interface, indicating at each time whether they were playing "with", "against", or "without" their partner. At an individual level, we found that musicians largely intended to converge with their co-improviser, making only occasional use of non-cooperative or non-interactive modes such as "playing against" or "playing without". By contrast, at the group level, musicians tended to combine their relational intents in such a way as to create interactional dissensus. We also demonstrate that co-presence and familiarity act as interactional smoothers: they increase the agents' overall level of relational plasticity and allow for the exploration of less cooperative behaviors. Overall, our findings suggest that relational intents might function as a primary resource for creative joint actions.

. But they are nonetheless distinct and can be dissociated.

On the one hand, some joint actions do not rely on interactions. For example, in highly compartmentalized processes of industrial production, each agent is receiving her own sub-task to do, without any interference with the sub-tasks of the others. Some joint actions can also rely on a mere asymmetrical coupling of agents, with one agent "acting or deciding as she does at least in part because of the observed or expected actions or decisions of the other agent" [START_REF] Michael | Prosocial effects of coordination -What, how and why?[END_REF], while the other remains impervious to what her co-agent is doing -think of a capricious singer expecting from her accompanist to follow her every move but making no effort in adjusting to her. In those cases, agents are not really interacting, yet, they still cooperate, in the sense that their individual actions are organized towards the achievement of some shared goal.

On the other hand, joint actions are not always cooperative: in joint actions involving some degree of negotiation, such as two friends discussing in order to decide which movie to watch, or conflict, such as two friends playing a tennis match, cooperation can be sporadic, or only present in a very weak sense. Indeed, while the two friends can still be said to organize their own individual actions in order to achieve some broad overarching goal (e.g., actually playing a match of tennis or actually watching a movie), they are doing so by aiming at proximate goals that are clearly distinct (e.g., watching such or such movie), or even incompatible (e.g., winning the game). Yet, in those cases, agents are still interacting, in the sense that each one's actions and decisions are dependent on the other's own actions and decisions.

Creative joint actions are an interesting class of actions to consider in that perspective.

Agents engaged in creative joint actions (such as dance contact improvisation, or brainstorming meetings) typically aim at producing something that has some novel character and/or some degree of unpredictability [START_REF] Amabile | Social psychology of creativity: A consensual assessment technique[END_REF]. However, it is not clear that such creative endeavors are always the results of strictly cooperative and interactive joint actions. For example, it has recently been shown that synchrony in joint action can be negatively associated with aesthetic appeal when the goal of the joint action is the creation of a complex product rather than interpersonal coordination itself [START_REF] Wallot | Beyond synchrony: joint action in a complex production task reveals beneficial effects of decreased interpersonal synchrony[END_REF]. Similarly, [START_REF] Bjørndahl | Agreeing is not enough: The constructive role of miscommunication[END_REF] highlight the critical role of miscommunication, including disagreements and misunderstandings, in collaborative creative activities such as jointly constructing LEGO models for abstract concepts such as "Justice" or "Knowledge". The studies discussed in [START_REF] Nemeth | Better than individuals? Dissent and group creativity[END_REF] also point in the same direction -with dissent taken to be a stimulator for creative thought in group tasks such as word associations.

Taken together, these results open up the possibility that agents engaged in creative joint action might deliberately avoid to interact or to cooperate with one another on a continuous basis. On the contrary, they might strategically attempt to create phases of noninteraction -consisting of uncoupled or desynchronized individual actions -and/or phases of non-cooperation -consisting of opposing or incongruent actions -as a way to reinforce the creativity of their endeavor.

We investigate here this hypothesis by using as an experimental paradigm the musical genre of collective free improvisation (CFI for short). In CFI, musicians typically play together without any pre-established plans or individual roles [START_REF] Pressing | Cognitive processes in improvisation[END_REF][START_REF] Bailey | Improvisation Its nature and practice in music[END_REF]. Nothing is specified in advance beyond the very general and abstract goal of making some (aesthetically satisfying) music that is as unprecedented as possible [START_REF] Wilson | The sign of silence: Negotiating musical identities in an improvising ensemble[END_REF]. In many ways, CFI provides a paradigmatic example of group creativity [START_REF] Cook | Music as creative practice[END_REF]. First, CFI performances are typically a case of emergent creativity [START_REF] Sawyer | Group creativity: Music, theater, collaboration[END_REF]. Since there is no preexisting blueprint upon which the performance is built, the whole performance emerges entirely, and more or less unpredictably, from the interactional dynamics at play between the improvisers. Second, CFI performances are typically a case of distributed creativity [START_REF] Sawyer | Distributed creativity: How collective creations emerge from collaboration[END_REF]. CFI performances generally take place within an egalitarian framework, with no pre-established leader. As such, individual roles and creative contributions to the overall output are constantly shifting and renegotiated over the course of the performance, and the creativity of the performance crucially depends on the way improvisers dynamically relate to one another. Interpersonal relations are thus at the very core of the practice of CFI [START_REF] Clarke | Creativity in performance[END_REF], the musicians' dialogical engagements with one another acting as one of the primary locus of CFI's aesthetic distinctiveness (Canonne, 2018a).

Based on the conceptual framework introduced above, we distinguish here between three main relational intents -three distinct ways of intending to relate to what one's coimproviser is doing. "Playing with" can be seen as a kind of default relational intent for joint musical improvisation, in which a given musician intends to both interact and cooperate with the other musician, by offering something which is broadly consistent with what she is doing.

"Playing against" can be seen as a relational intent in which a given musician does not intend to cooperate with the other musician, by willingly opposing what she is doing. Finally, "playing without" can be seen as a relational intent in which a given musician does not intend to interact with the other musician, by simply ignoring what she is doing. Note that we refer here to intentions. A musician might intend to play "without" her co-improviser but fail to do so, because she simply cannot avoid being influenced by her co-improviser. In other words, it might not always be easy to infer a given musician's relational intent based on the overall musical result.

The study we report here had two main goals. Our first goal was to empirically investigate how improvisers dynamically relate to one another over the course of the performance. To what extent improvisers actually endorse "non-cooperating" and "noninteracting" relational intents? To what extent do they tend to endorse identical or similar relational intents towards one another? Are there some combinations of relational intents that are more frequent than others? Are "playing against" or "playing without" used in the same way and with the same stability as "playing with"?

The second main goal of our study was to assess the impact on the musicians' relational intents of two factors that are often taken to play an important role in explaining coordination during CFI, namely the familiarity between the musicians and the co-presence of the musicians within the same physical space [START_REF] Bishop | Collaborative musical creativity: How ensembles coordinate spontaneity[END_REF]. Familiarity could impact musicians' interactions in two directions: on the one hand, musicians who are used to play with each other are likely to develop an increased sense of trust and confidence towards one another, which might help the group to take more risks [START_REF] King | Social familiarity: styles of interaction in chamber ensemble rehearsal[END_REF], or to allow for a less conscious approach to interaction [START_REF] Wilson | The construction of meaning within free improvising groups: A qualitative psychological investigation[END_REF]; but on the other hand, low familiarity can also enable less predictable interactions, and be an incentive for more creative behaviors [START_REF] Levine | Newcomer influence and creativity in work groups[END_REF]. As for physical co-presence, it enables the perception of subtle visual and somatic cues [START_REF] Novembre | Music and action[END_REF] which might play an important role in the musicians' coregulation, supporting the emergence of a "we-space" in which a feeling of togetherness can emerge [START_REF] Krueger | Extended cognition and the space of social interaction[END_REF]. Conversely, physical separation might impair musicians' empathetic attunement [START_REF] Seddon | A comparison of modes of communication between members of a string quartet and a jazz sextet[END_REF], potentially resulting in the musicians taking fewer risks (Iowerth and Knox, 2019). Beyond their impact on musical coordination, we thus expect familiarity and co-presence to have an impact on the way CFI performers actually intend to relate to one another when improvising, notably by allowing for more divergence or more autonomy between the performers.

Our study provides a first step in investigating those different issues, by enabling the quantitative exploration of the musicians' relational intents in a newly recorded corpus of 40 freely improvised duo performances, and by controlling for both the familiarity between the musicians and their physical co-presence.

Methods

Participants

Our participants were recruited from the Parisian Free Improvisation scene. The Parisian Free improvisation scene is one of the most dynamic scenes in Europe, with many concert venues and a dense network of musicians, both professional and amateur, coming from a wide variety of stylistic backgrounds, such as noise music, western contemporary music, jazz/free jazz, or minimalism [START_REF] Roueff | L'invention d'une «scène» musicale, ou le travail du réseau[END_REF]. After an extensive fieldwork conducted over the last years, the last author of this paper had gathered the contact information from many professional improvisers active in the Parisian Free Improvisation scene [START_REF] Canonne | Rehearsing Free Improvisation? An Ethnographic Study of Free Improvisers at Work[END_REF]). An invitation was thus sent through email to 50 professional musicians to participate in our study. The email indicated that we were looking for professional musicians to participate in an experiment on collective improvisation, that the experiment would consist in both performing and listening, that the duration of the experiment would be roughly 2 hours, and that the musicians would be paid for their contribution. Twenty improvisers accepted this invitation, and were available to participate in the experiment (male: 14, mean age = 39, sd = 10.7). All were highly trained musicians (range: 17-50 years of musical practice) and had substantial improvisation practice (range: 5-30 years of free improvisation practice). Half of the participants was recruited as duos of musicians who had previous experience improvising with one another, whereas the other half was paired so as to create duos who had close to none. Their instruments were saxophone (N = 6), trumpet (N = 3), piano, guitar, cello (N = 2), double bass, viola, bass guitar, voice, euphonium (N = 1). All participants gave their informed written consent.

Procedure

The experiment took place in a professional recording studio at the Institute for Research and Coordination in Acoustics/Music (IRCAM) in Paris. Each duo was asked to perform 4 improvisations running from approximately 5 to 10 minutes (mean = 386s, sd = 152s). Two of these were performed in the same room ("Co-present" condition) whereas the two others were performed in separate booths ("Isolated" condition). In this latter condition, musicians could not see each other but were hearing each other through headphones, as is standard in studio recording practice. Duos 1-5 played in the Co-present condition first, while duos 6-10 played in the Isolated condition first. All the performances were recorded by a professional sound engineer.

Immediately after the recording session, participants were asked to listen back in randomized order to the improvisations they had performed and to annotate them using a web application (see Figure 1). The web client, running in a regular web browser, was connected to a server through a bidirectional and persistent communication channel to send and store annotations on the server in real-time as well as to provide information to the experimenters through a remote monitoring panel [START_REF] Matuszewski | Soundworks -A Framework for Networked Music Systems on the Web -State of Affairs and New Developments[END_REF]. The Center zone of the triangle (in black in Figure 1) was described as a zone of interactional indeterminacy, to be used in cases where the participants thought that their behavior did not conform to any of the aforementioned relational intents. The position of each of the relational intents on the three vertices were randomized for each participant.

While listening back to the performances, participants could drag a white dot on the triangle with a mouse to indicate what was their relational intent towards their partner at each time during their improvisations (see this link for a few video examples of participants' annotations). Each time a change occurred in the interface, the normalized position of the dot according to the center of the triangle was sent to the server to be stored in a file along with the current time of the sound file. Four areas were clearly delineated on the triangle to help the participants navigate the interface, but in our instructions we emphasized the fact that the interface was continuous, and participants were encouraged to indicate the intensity to which they conformed to each relational intent by varying the distance to the corresponding vertex.

After the annotation task, we assessed musicians' familiarity with each other by asking the participants to report how much they were used to play with each other in the context of CFI on a scale from 1 (not familiar at all) to 7 (very familiar). For each duo, the two musicians' familiarity ratings were then averaged to assess the overall level of familiarity of the duo. We also asked the musicians to report how aesthetically close they felt to the other musician on a scale from 1 (not close at all) to 7 (extremely close). Because of the strong correlation between aesthetical proximity and familiarity (ρ (pearson) = 0.56, p = 0.01), we decided to use only the latter in our analysis to avoid redundancy. Due to some technical issues in communicating with the server for collecting the data, annotations for duo 1 (tracks 3 & 4) and duo 2 (track 2) were lost.

Data pre-processing

Annotation data were preprocessed by linearly interpolating between time points with a resolution of 4 Hz. This value was chosen as a compromise between being low enough as to capture most of the movements of the participants in the interface, and high enough so as to reduce the size of the dataset for data analysis.

Synoptic graphs of the annotations were produced indicating at each time which area of the triangle (i.e., "with", "against", "without" or "center") each musician was in. Two examples of such graphs can be seen in Figure 2 1 . As can be seen in Figure 2, there was a lot of variability between the performances (including between performances by the same duo):

for example, the musicians' relational intents were much more stable and continuous in Duo 5 Track 4 than in Duo 6 Track 1. Similarly, the relational intents were much more symmetrical in Duo 5 Track 4, in which both musicians reported intending playing "with" one another for a large amount of the performance, than in Duo 6 Track 1, in which musicians often reported distinct relational intents. Below, we investigate some of the factors that might account for this variability. and duo 5, track 4 (bottom). Green (resp. red, blue) indicates that the musician was in the "with" (resp. "against", "without") area. The further from the corresponding vertex, the lighter the color. White corresponds to the center area

Variables

The interface used in our annotation task allowed us to identify the relational intents (i.e., intentions to play "with", "against", or "without" their co-improviser) endorsed by the musicians at each time during the performance, simply by examining in which area of the triangle the participants were at each time. But our interface also allowed us to gather information on several important aspects of the musicians' interactional dynamics that could be impacted by the musicians' familiarity with one another and/or their co-presence within a shared physical space.

To assess the improvisers' relational plasticity (i.e., the improvisers' general tendency to change their relational intent over the course of the performance), we computed two complementary measures for each musician and each performance. First, we estimated the mean speed of the navigation in the interface (computed as the total distance covered in the interface divided by length of improvisation). Second, we computed the number of areas that the musician visited during the performance (normalized by the length of the improvisation).

To assess the degree of interactional consensus between the two musicians (i.e., the improvisers' general tendency to intend to play "with" one another or to endorse identical relational intents), we used three complementary variables. First, we computed, for each musician and each performance, the proportion of time she was in the "with" area, as delineated by the dashed lines in our interface. Second, we computed, for each performance, the proportion of time the two musicians were in the "with" area (first-order agreement). Lastly, we computed, for each performance, the proportion of time the two musicians were in the same area (second-order agreement, e.g., musicians agreeing on playing against each other).

Finally, to assess the intensity with which improvisers conformed to each relational intent (i.e., the extent to which each one of the three main relational intents tended to "attract" the improvisers), we computed, for each musician and each performance, the mean distance between her position within the interface and each one of the three vertices of the triangle. This gave us three variables: Distance to the "with" vertex; Distance to the "against" vertex; and Distance to the "without" vertex.

Statistical analysis

We assessed the effects of co-presence and familiarity on each of the variables introduced in the previous section. Importantly, we tested for both a linear and a quadratic relation between our variables and the familiarity between the musicians, as the relationship between familiarity and relational intents may follow a U-shaped function (as explained in the introduction).

For each variable, hierarchical regressions were conducted by comparing nested models [START_REF] Gelman | Data analysis using regression and multilevel/hierarchical models[END_REF], starting with a null model and adding first co-presence and then powers of familiarity (using the R function ordered) to examine both potential linear and quadratic effects. Duo (when the dependent variable was dyadic) or musician (when the dependent variable was individual) ID were entered as a random intercept, and co-presence as a random slope (as it varied within duo). Potential interactions between co-presence and familiarity were also tested. Thus, the successive models were the following: The models were fitted with the function lmer from the R package lme4 and compared using a likelihood ratio test, with Satterthwaite estimations of degrees of freedom. In the section "Effects of co-presence and familiarity on musicians' interactional dynamics" below, we report the results of model comparisons, as well as beta, standard errors, t-values and p-values for the effect of co-presence and familiarity on each dependent variable.

Acoustic analysis

Our experimental set-up made it possible to systematically compare the relational intents indicated by the participants with the music they had actually performed. In particular, we were interested in investigating whether there was something distinctive in their musical behavior when improvisers intended to both play "with" one another, as compared to situations in which at least one musician did not intend to play "with" her partner. The general idea was to test whether musicians were more acoustically coordinated in the former case than in the latter.

Since we did not have access to the musicians' individual tracks for the improvisations performed in the "co-present" condition (because the music produced by one of the musician's was necessarily picked up by the microphone used to record the other musician's microphone), we thus only relied on the improvisations performed in the "isolated" condition to run our acoustic analysis.

We selected three acoustic features that reflect meaningful properties of CFI performances [START_REF] Goupil | Emergent Shared Intentions Support Coordination During Collective Musical Improvisations[END_REF] to run our analysis:

-Root-Mean-Square (related to the musician's loudness) -Spectral centroid (related to the musician's timbre) -Fundamental frequency (f0) estimate (related to the fundamental frequency of the sounds produced by the musician) These features were computed on all of the individual WAV files, using the python library Librosa with a window size of 46 milliseconds, ending up with three vectors of data for each musician and each performance. These data were linearly interpolated between time points with a resolution of 4 Hz so as to match the same time points as the annotation data. We then computed two Pearson correlation coefficients for each performance: one between the vectors of data at the times when both musicians intended to play "with" one another ("withwith" condition) and the other between the vectors of data at the times when at least one musician did not intend to play "with" her partner ("other" condition). We then assessed whether or not improvisers' musical outputs were more correlated whenever they both reported having played "with" one another. To do this, we performed a logistic mixed regression including "with" (yes or no) as a dependent variable, RMS correlations, f0 correlations, and spectral centroid correlations as independent variables, and duo as a random intercept.

Results

Relational intents in freely improvised duets

Our experimental setup allowed us to gather some crucial insights on the distribution of the musicians' relational intents in freely improvised duets. Figure 3 shows a pie chart of the distribution of the relational intents within our corpus. We found that, on average, musicians spent 58.3% (sd: 21.3) of their individual playing time in "with", 11.2% (sd: 13.3) in "against", 13.4% (sd: 13.4) in "without" and the rest in the "center" area. As expected, "playing with" the other musician was, by far, the most common relational intent. However, it should be noted that, even if they were largely attracted by the "with" area, musicians seemed to favor relational intents that had some degree of ambiguity, as reflected by the fact that the mean positioning of the musicians within the interface was in fact situated in the "center" area, albeit quite close from the "with" area (see Figure 1 above). Musicians also allowed for non-cooperative or noninteractive intents in a more occasional but still significant way, "playing against" and "playing without" the other musician amounting for 24.6% of the total playing time. Interestingly, "playing against" and "playing without" were used in a much more transient fashion than "playing with". The average duration of a stay in the "with" area (M = 41.6s, sd: 60.4) was significantly longer than the average stay in the "against" area (M = 11.1s, sd: 13.4; t = 4.23, df = 80, p-value = 6.1e-05) and in the "without" area (M = 17.3s, sd: 24.2; t = 3.20, df = 96, p-value = 0.0018). This is consistent with the idea that non-cooperative and noninteractive relational intents were mainly used as a way to momentarily disrupt the ongoing situation. "Playing against" and "playing without" could also have been used as short interactional signals, "open angles" which afford the other musician with the possibility of introducing a new idea or modifying her own behavior (Denzler & Guionnet, 2020: 26).

Musicians' combinations of relational intents

Figure 4 shows a pie chart of the distribution of the combination of relational intents observed in our corpus. A few conclusions can be drawn from it. First, we found that cases of symmetrical intentions to be independent were fairly rare: musicians were both intending to "play without" each other only 1.3% of the time. However, asymmetrical couplings between the musicians (i.e., cases in which one of the musicians was intending to play "without" the other) were much more common, amounting to 24.6% (sd: 17.2) of the total playing time.

Second, and similarly, we found that highly antagonistic interactions were rather uncommon: musicians were both intending to "play against" each other only 2.8% of the time.

However, interactions with some degree of antagonism (i.e., cases in which one of the musicians was intending to play "against" her partner), while still occasional, seemed to represent a viable strategy for our participants, amounting to 17.8% (std : 17.4) of the total playing time.

Third, we found that, on average, musicians spent 41.8% (sd: 19.1) of the time in the same area -the case in which both musicians were both intending to play "with" one another amounting for a vast majority of that time (36.2% of the total playing time). This also means that, for more than half of their playing time, musicians actually had distinct relational intents.

In other words, musicians tended to combine their relational intents so as to avoid strict relational alignment, and to create a certain amount of interactional dissensus. Interestingly, musicians were much more likely to intend to play "against" or "without" the other when their co-improviser was actually trying to play "with" them. This could suggest that improvisers were only allowing themselves to explore more incongruent relational intents if they felt that their co-improviser was, for her part, displaying a cooperative behavior, thus providing a minimal degree of stability at the level of the dyad.

Effects of relational intents on acoustic coordination

As a preliminary result, it should be noted that we found that the improvisers' musical behaviors were significantly correlated to one another for RMS (t(8) = 8.55, p < 0.001) and spectral centroid (t(8) = 3.96, p = 0.004), and marginally so for f0 (t(8) = 2, p = 0.08). This means that, independently of how they intended to relate to one another, musicians manifested a substantial degree of acoustic alignment over time, at least in terms of loudness (i.e., they tended to play with a similar level of energy) and timbre (i.e., they tended to use instrumental timbres that had a similar level of brightness).

More importantly, we found that these correlations varied as a function of the musicians' relational intents. In a logistic mixed regression including "with" (yes or no) as a dependent variable, RMS correlations, f0 correlations, and spectral centroid correlations as independent variables, and duo as a random intercept, we found that the probability that musicians would both be attempting to play "with" one another was higher when improvisers' sonic behaviors were more correlated in terms of RMS (beta = 6.37, sem = 3.1, z = 2.06, p = 0.03, X2 = 4.97) and marginally so for f0 (beta = 5.9, sem = 3.5, z = 1.7, p = 0.08, X2 = 3.14) (the effect of spectral centroid was not significant, p > 0.9).

As shown in Figure 5, post-hoc paired comparisons revealed that musicians' RMS were significantly correlated when both musicians intended to play "with" one another (t(8) = 6.53, p < 0.001) but also in cases in which at least one musician did not intend to play "with" her partner (t(8) = 11.5, p < 0.001). Crucially, however, we found that musicians' RMS were significantly more correlated in the former case than in the latter case (t(8) = 2.82, p = 0.02).

Musicians' f0s were significantly correlated when both musicians intended to play "with" one another (t(8) = 2.23, p = 0.05) but not when at least one musician did not intend to play "with" her partner (t(8) = 0.83, p = 0.4), although the difference between the two cases was not significant (t(8) = 1.7, p = 0.12). Finally, musicians' spectral centroids were significantly correlated when both musicians intended to play "with" one another (t(8) = 3.45, p = 0.009) and also when at least one musician did not intend to play "with" her partner (t(8) = 3.45, p = 0.009), with a non-significant difference between the two cases (t(8) = 0.25, p = 0.8).

Overall, these results show that when both musicians intended to play "with" one another, they tended to display a higher degree of acoustic coordination, at least in terms of loudness: they were particularly careful to balance their individual levels of energy.

Conversely, the greater imbalance observed when at least one musician intended to play "against" or "without" her partner gives additional support to the idea that such relational intents could have effectively been used by the musicians as a way to disrupt the ongoing situation or challenge their partner.

Effects of co-presence and familiarity on musicians' interactional dynamics.

Having examined in detail the relational intents reported by the participants in this study and the way such intents translated in the performers' acoustic production, we next turned to assessing whether the musicians' interactional dynamics was impacted as a function of our two variables of interest: co-presence and familiarity. The full output of the models described above is given in Table 1. Note that no significant interactions were found between co-presence and familiarity. Although model comparisons indicated a significant interaction between copresence and powers of familiarity in the case of the "mean speed" variable, as can be seen in

Co-presence favor more antagonism between the musicians and higher interactional dissensus

There was a statistically significant relationship between co-presence and distance to "with" (χ 2 = 6.56, p = 0.01), and between co-presence and distance to "against" (χ 2 = 7.17, p = 0.007).

As shown in Figure 6, co-presence was found to increase the distance to "with" (β= 0.099, sem = 0.037, df = 54.8, t = 2.65, p = 0.011) and conversely to decrease the distance to "against" (β= -0.084, sem = 0.031, df = 49.9, t = -2.74, p = 0.008). Similarly, co-presence had a main effect on the time spent in "with" (χ 2 = 9.74, p = 0.009), the time in which both musicians were in the "with" area (χ 2 = 6.39, p = 0.011), and the time in which the two musicians were in the same area (χ 2 = 6.17, p = 0.013). As shown in Figure 7, musicians co-presence tended to spend less time in the "with" area (β= -0.106, sem = 0.039, df = 51.3, t = -2.71, p = 0.009). Moreover, when in co-presence, the two musicians tended to be less often in the "with" area at the same time (β = -0.158, sem = 0.048, df = 37.0, t = -3.27, p = 0.002), and to spend less time in the same area (β= -0.132, sem = 0.045, df = 37.0, t = -2.95, p = 0.005). Overall, our results thus show that, when co-present, musicians were less likely to intend to converge with their co-improviser and to adopt similar relational intents. This suggests that co-presence allows for the exploration of more ambiguous and less consensual relationships, with both a higher degree of antagonism (as attested by the fact that participants tended to be closer from the "against" vertex when co-present), and a higher degree of interactional dissensus (as attested by the fact that participants tended to spend less time playing with the same relational intent).

High and low familiarity favor higher interactional dissensus between the musicians and higher relational plasticity

As with co-presence, familiarity was found to have a significant effect on the amount of time during which the two musicians were in the same area (χ 2 = 15.8, p = 0.015), and the time in which they were both in the "with" area (χ 2 = 13.9, p = 0.030). As shown in Figure 8, and as predicted, these variables varied in a "inverted U-shaped" way as a function of familiarity: both high and low familiarity were associated with less time spent with similar relational intents (quadratic effect of familiarity on the time spent in the same area: β = -0.149, sem = 0.063, df = 37, t = -2.38, p = 0.023) and intentions to "play with" one another (quadratic effect of familiarity on the time spent in with-with: β= -0.189, sem = 0.068, df = 37, t = -2.80, p = 0.008). Moreover, the analysis revealed a main linear and quadratic effect of familiarity on variables associated with relational plasticity such as mean speed of movement (χ 2 = 21.6, p < 0.001) and number of visited areas per second (χ 2 = 17.1, p = 0.009). Given our initial hypothesis that familiarity should have a quadratic effect, and the fact that the quadratic term more closely captured the overall complexity of our data, we focus on interpreting the quadratic term over the linear term in the remaining. As shown in Figure 9, both high and low familiarity were found to be associated with a higher speed (quadratic effect of familiarity on mean speed: β = 0.042, sem = 0.010, df = 18.8, t = 4.16, p < 0.001) and a greater number of visited areas per second (β = 0.026, sem = 0.006, df = 15.5, t = 4.10, p < 0.001). Overall, our results thus show that musicians with both high and low familiarity were less likely to intend to converge with the other at the same time and to endorse similar relational intents. Interestingly, they also changed more swiftly and more frequently from one relational intent to another. This suggests that both high and low familiarity stimulate musicians' relational plasticity in a context such as collective free improvisation, and we come back to this issue in the discussion.

Discussion

Dissensus in Collective Free Improvisation

Our study sheds light on the relational strategies used by musicians when they freely improvise together. In particular, we show that, while, at an individual level, musicians largely intend to converge with their co-improviser, making only occasional use of non-cooperative or noninteractive strategies such as "playing against" or "playing without" their co-improviser, they nonetheless tend to combine their relational intents in such a way as to create focal interactional dissensus. Such emphasis on "dissensual" interactions seems to challenge the dialogue metaphor that is so widely used to describe collective improvisation [START_REF] Benson | The improvisation of musical dialogue: A phenomenology of music[END_REF]. The fact that musicians typically improvise together in CFI without previously agreeing upon on a shared framework necessarily increases divergences in understanding and appreciation among the performers [START_REF] Pras | What about their performance do free jazz improvisers agree upon? A case study[END_REF]. There is also a wider cultural aspect at play, here: CFI has a long history of operating as an improvisation forum [START_REF] Borgo | Sync or swarm: Improvising music in a complex age[END_REF], bringing together performers from various musical backgrounds. This conception was for example at the core of Derek Bailey's famous Company Weeks festival [START_REF] Watson | Derek Bailey and the story of free improvisation[END_REF]. As a result, free improvisers "will inevitably bring contrasting shades of understanding to what they play together" (MacDonald & Wilson, 2020, p. 99), that are likely to reinforce feelings of playing "against" or "without" one's partner amongst CFI performers.

More generally, the interactional dissensus observed in CFI is highly dependent on the specificities of the musical medium. First, the "floating intentionality" of the musical medium [START_REF] Cross | Music and communication in music psychology[END_REF] -the fact that, musical semantics is, at best, highly underspecified [START_REF] Schlenker | Outline of music semantics[END_REF] -means that musicians can actively play "against" their partner without actually contradicting each other and bringing the interaction to a deadlock. Second, the simultaneity of the improvisers' individual contributions to the overall musical output favors a higher degree of independence, making the improvisers' behaviors less contingent on one another. Those two features put CFI in stark contrast with the interactional dynamics of improv theater, which relies on turn-taking and, at least most of the time, on the avoidance of both semantic and fictional contradictions. As such, the "yes-and" mantra -acknowledging your co-improviser's offer and building on it -that is often considered to be improv's one essential rule [START_REF] Besser | The Upright Citizens Brigade Comedy Improvisation Manual[END_REF] does not capture the complexity of CFI, musicians being able to explore a wider range of interactions, including local dissensus.

Our results also suggest that, in a mostly egalitarian framework such as CFI, in which musicians are thought to be contributing equally to the overall output, interactional dynamics are also largely driven by the manipulation of more "horizontal" relationships. Such ways of relating to one another that do not necessarily translate into "vertical" relationships such as leading or following, but rather unfold on a spectrum that goes from cooperation to indifference and conflict. This does not mean that leader/follower patterns -understood either in terms of sent information [START_REF] Pelz-Sherman | A framework for the analysis of performer interactions in western improvised contemporary art music[END_REF] or in terms of temporal precedence in initiating a musical phrase or situation [START_REF] Aucouturier | Musical friends and foes: The social cognition of affiliation and control in improvised interactions[END_REF] -do not emerge locally during the performance. But our study invites to consider those "horizontal" relationships as a relevant complementary axis for the analysis of social interactions in collective musical performances, beyond the more traditionally studied leader/follower relationships [START_REF] Volpe | Measuring social interaction in music ensembles[END_REF][START_REF] Chang | Body sway reflects leadership in joint music performance[END_REF].

Non-interactive behaviors in Collective Free Improvisation

One of the most striking result of our study is probably the significant amount of performance time during which the improvisers were, in fact, not intending to interact with their partner.

Musicological scholarship has already discussed the possibility that the importance of interaction in jazz performances had been overemphasized, because of a tendency to frame as interactional processes what is just musicians "independently fulfilling their own musical functions in a creative way" (Rinzler, 1988, p. 156; see also [START_REF] Givan | Rethinking interaction in jazz improvisation[END_REF]. Providing a computational analysis of interactions within a jazz quintet, [START_REF] Pachet | Do jazz improvisers really interact?[END_REF] come to similar conclusion, showing that musicians' acoustical outputs do not exhibit a higher degree of correlation than what is already provided by the musical script they all share.

However, the occasional absence of interactions might be more surprising in the context of CFI, in which there is no external script, or even no clearly shared and well-defined stylistic idiom that can "glue" together the individual contributions into a joint musical outcome. In CFI, the feeling of playing together crucially depends on the degree of contingency each performer displays towards the actions of her co-performers. The fact that free improvisers are sometimes willing to put the jointness of their performance at risk -as shown by the lower degree of acoustic coordination displayed in situations where at least one musician was not intending to play "with" her partner -is thus not trivial. Several non-exclusive reasons might be offered here to explain such behavior. First, this might reflect the wider influence of a post-Cagean aesthetics on some "eurological" strains of CFI [START_REF] Lewis | Improvised music after 1950: Afrological and Eurological perspectives[END_REF], according to which there is much beauty to be found in the serendipitous juxtapositions and superpositions of independent sounds. Second, asymmetrical couplings (i.e., one musician's behavior being contingent on the other's, but not reciprocally) might be enough to preserve a feeling of jointness while still offering the musicians with many surprising events, prompting their musical behavior in unexpected directions. Third, it might be that, even when they intend to "play without", improvisers are not really able to fully abstract their playing from what their physically and/or sonically co-present partner is doing, and still display some minimal degree of contingency in their behaviors. Indeed, research has shown that agents' tendency to align their behaviors can be very pervasive, and remain even when they have no intention to coordinate with one another [START_REF] Issartel | Unintended interpersonal co-ordination: "can we march to the beat of our own drum?[END_REF]. Further experiments could test this last hypothesis by comparing the perceived degree of togetherness in real duets in which free improvisers are actually trying to play without each other, with that of "fake" duets made up of randomly combined individual tracks.

Co-presence and familiarity act as interactional smoothers

Another main contribution of our study is to demonstrate that co-presence and familiarity notably impact improvisers' relational intents towards one another. While both factors similarly increased the overall level of interactional dissensus, they also modulated differently improvisers' individual behavior, with co-presence increasing the degree of antagonism improvisers were willing to inject in their interactions, and both low and high familiarity increasing their relational plasticity. They thus deserve separate discussions.

Regarding co-presence, two explanations might explain its impact on the musicians' interactions. First, many studies have highlighted the role played by facial expressions and perception of bodily movements in musical coordination and synchronization [START_REF] Davidson | Bodily movement and facial actions in expressive musical performance by solo and duo instrumentalists: Two distinctive case studies[END_REF][START_REF] D'ausilio | Leadership in orchestra emerges from the causal relationships of movement kinematics[END_REF][START_REF] Hilt | Multi-layer adaptation of group coordination in musical ensembles[END_REF]. Such visual cues enhance coordination mainly because they allow musicians to better monitor the expressive intentions of their fellow group members, through a variety of mechanisms such as perceptual-motor couplings [START_REF] Novembre | A conceptual review on action-perception coupling in the musicians' brain: what is it good for?[END_REF], or audio-visual integration [START_REF] Mcgurk | Hearing lips and seeing voices[END_REF][START_REF] Thompson | Audio-visual integration of emotional cues in song[END_REF][START_REF] Bishop | Context-specific effects of musical expertise on audiovisual integration[END_REF]. This is likely to make it easier for musicians to coordinate, e.g., to synchronize their attacks or to match each other's levels of loudness. Here, co-present improvisers might have been better able to perceive their partner's intention to play "with" them, which in turn made it possible for them to explore more antagonistic modes of interactions that could have, in less favorable contexts, put at risk the musicians' felt connection to one another. In a similar perspective, they may also have been able to play "against" their partner in a more robust fashion, because they were able to better anticipate the musical direction taken by their partner, which made it easier for them to actually diverge from their co-improviser when they wanted to do so. Conversely, it is likely that musicians tended to play "with" their partner more often in the "Isolated" condition precisely to try to make themselves more predictable, thus counterbalancing for the increased difficulty of coordination caused by the absence of visual and bodily cues [START_REF] Vesper | Making oneself predictable: Reduced temporal variability facilitates joint action coordination[END_REF][START_REF] Goupil | Emergent Shared Intentions Support Coordination During Collective Musical Improvisations[END_REF].

Second, in the case of collective improvisation, [START_REF] Moran | Perception of 'back-channeling' nonverbal feedback in musical duo improvisation[END_REF] found evidence of a backchannel of communication between soloing improvisers and momentarily silent coperformers based on bodily cues. In particular, third-party listeners were able to tell whether musicians were actually playing together or not simply by looking at their bodily movements.

Such back-channeling communication, accessible through bodily and visual cues, might thus comfort improvisers that they are indeed playing music together, and reinforce a shared feeling of togetherness. It is then likely that "Isolated" musicians felt that they had to make up for the lack of subtle visual and somatic cues that are so crucial in creating a feeling of togetherness by overly emphasizing that they were playing "with" their partner.

The results we obtained regarding familiarity also deserve further discussion, as they reveal a complex, non-linear effect of familiarity. We found that the degree of relational plasticity was increased when musicians had virtually never played together before. Two interpretations of these results are possible. On the one hand, it might be that the novelty of the situation encouraged the improvisers to explore a wider variety of musical relationships and to change their interactional behavior more rapidly as a way to get to know their partner. On the other hand, it might be that the lack of familiarity, and the higher stylistic or aesthetic heterogeneity that might often come with it, made it simply more difficult for the musicians to monitor and anticipate their partner's behavior [START_REF] Ragert | Knowing too little or too much: the effects of familiarity with a co-performer's part on interpersonal coordination in musical ensembles[END_REF], thus preventing them to stabilize their interactions for a longer stretch of time. In the absence of more detailed data regarding the improvisers' subjective evaluations and descriptions of the performances, it is difficult to assess the respective relevance of these two interpretations. In any case, a clearer result is that musicians that were somewhat familiar with each other displayed a lower relational plasticity than musicians with higher familiarity or no familiarity at all. In a way, those musicians knew each other well-enough for having established a minimal common ground that made it unnecessary to "uncover" through the performance the range of viable musical relationships they could explore together. But they were not familiar enough with one another as to share an implicit mental model of what it is to improvise together, in the same way as improvisers who are highly familiar with one another do [START_REF] Canonne | Play together, think alike: Shared mental models in expert music improvisers[END_REF]. Such shared mental models may entail similar mappings between sound-types and action-types, making it more likely for the improvisers to "pick up" on the same sonic events, thus strongly contributing to the feeling of trust and confidence improvisers might feel towards one another. It also made it possible for them to engage in a more playful performance, in which they could constantly change their relations to one another as a way to surprise each other and reinforce the unpredictability of the performance. As such, it would appear that Derek Bailey's position -which claims that the most stimulating improvisations come from groups that are still "fresh" -and the position of many contemporary improvisers within the CFI scene [START_REF] Canonne | Rehearsing Free Improvisation? An Ethnographic Study of Free Improvisers at Work[END_REF] -who insist on the importance of knowing each other "very well" to be able "to stretch it further" (Denzler & Guionnet, 2020, p. 19) -are less incompatible than it would seem at first sight. In both cases, albeit probably for different reasons, musicians seem able to create the kind of interactional tension that is often thought to be so crucial to CFI. On a more general note, our results point towards the existence of a U-shaped relationship between familiarity and relational plasticity within a group. Future experiments could assess this hypothesis further by investigating more extensively the temporal dynamics of the impact of group familiarity on group members' interactional behaviors over a wider range of artistic and creative practices.

Co-presence and familiarity are often thought to unilaterally favor behavioral alignment. For instance, co-presence is thought to increase synchronized body movement and convergent emotional response through entrainment, even when people are not explicitly interacting [START_REF] Richardson | Rocking together: Dynamics of intentional and unintentional interpersonal coordination[END_REF]. As for higher familiarity between the group members, it is typically thought to lead to better synchronization in chamber music performance, through the progressive calibration of internal prediction models [START_REF] Keller | Ensemble performance: Interpersonal alignment of musical expression[END_REF]. But a more general interpretation would be that those factors act as interactional smoothers, increasing the agents' overall level of relational plasticity, and allowing for the exploration of a wider range of interpersonal relations. In other words, co-presence and familiarity can allow for both more congruent and more divergent behaviors, depending on what the context of action requires. In that sense, the fact that co-present musicians and highly familiar musicians were less likely to intend to converge with one another or to seek for relational alignment, can precisely be seen as a sign that CFI typically strives when there is some degree of interactional dissensus between the musicians.

Relational intents as creative resources in Collective Free Improvisation

Overall, our study gives additional empirical ground to the idea that agents engaged in creative joint actions typically oscillate between convergent behaviors and divergent behaviors, agreement and dissensus, contingency and autonomy, as a way to negotiate between the demands of doing something collectively and the goal of delivering a creative output. In that perspective, CFI's aesthetic success seems to have much to do with exploring the tension (and finding a balance) between individual autonomy and group cohesion. That free improvisers skillfully negotiate between the requirements of joint action (i.e., coordinating individual actions, feeling a sense of togetherness) and the requirements of creativity (i.e., favoring the serendipitous emergence of novel musical situations) is clearly reflected in the way they organized their interactions at the group-level, by favoring associations in which one musician was engaged in a disruptive behavior (e.g., challenging their improvisation partner by playing non-cooperatively) while the other was endorsing a more stabilizing behavior. As we showed, this typically resulted in musical situations in which the musicians' individual outputs were more acoustically incongruent, at least in terms of properties as fundamental as loudness.

However, it remains an open question whether such combination of behaviors actually result in a more creative or expressive result. Follow-up experiments could further investigate the relation between interactional behaviors and the aesthetic and creative properties of the musical output. For instance, we could ask third-party listeners to rate musical outputs with different combinations of relational intents (e.g., "with-with", "with-against", etc.) along several dimensions (e.g., "originality", "togetherness", "pleasantness", "arousal", etc.).

Relational intents might well function as a primary resource for creative joint actions, particularly when shared external resources are scarce, as it is the case in CFI; they are not just a parameter of the situation, set once and for all, but something that agents can actively work with over the course of the action. Musical improvisers work with such interpersonal relations in the same way as they work with notes or rhythms: they manipulate them as to create expressive effects, playing with our (and their own) expectations to build tension and

Figure 1 .

 1 Figure 1. Interface used by the participants for the annotation task. Participants navigated continuously within the triangle to indicate the intensity with which they conformed with a given relational intent, with white dashed lines delineating the limits of each area. The black area in the center corresponds to an area of interactional indeterminacy. The green dot shows the mean position of the musicians in the interactional space across the overall corpus.

Figure 2 .

 2 Figure 2. Graph indicating in which area of the triangle each musician was at each time for duo 6, track 1 (top)

  m0 (null model): dependent variable ~ 1 + (copresence | musician OR duo) m1: dependent variable ~ copresence + (copresence | musician OR duo) m2: dependent variable ~ copresence + ordered (familiarity) + (copresence | musician OR duo) m3: dependent variable ~ copresence * ordered (familiarity) + (copresence | musician OR duo)

Figure 3 .

 3 Figure 3. Distribution of the relational intents within the corpus.

Figure 4 .

 4 Figure 4. Distribution of the combinations of relational intents within our corpus.

Figure 5 .

 5 Figure5. Acoustic analysis. We show the average correlation values between musicians' volumes (Root-Mean-Square, left), spectral centroids (middle) and fundamental frequencies (right), computed separately for time periods during which both musicians were in the "with" area (dark green) or in other areas or configurations (light green). Error bars show the 95% confidence intervals. Black asterisks show the results of a logistic regression testing whether RMS/spectral centroid and pitch correlations predicted whether both musicians were in the "with"

Figure 6 .

 6 Figure 6. Mean distances between the position of the musician and the "with" (left) and "against" (right) vertices, depending on co-presence. Error bars show the 95% confidence intervals. * indicates significance with p < 0.05, ** p < 0.01.

Figure 7 .

 7 Figure7. Proportion of time spent by the musicians in the "with" area (left), proportion of time in which the two musicians were both in the "with" area (middle), and proportion of time in which the two musicians were in the

Figure 8 .

 8 Figure 8. Proportion of time in which the two musicians are in the same area (left) and proportion of time in which the two musicians were both in the "with" area (right), depending on familiarity. Data points show individual data. Blue line shows the best fitting quadratic regression line, with 95% confidence intervals

Figure 9 .

 9 Figure 9. Mean speed (left) and number of visited areas per second (right), depending on familiarity. Data points show individual data. Blue line shows the best fitting quadratic regression line, with 95% confidence intervals.

  momentum. Extending this insight to other forms of collective creative practice to explore how the diversity of interactional behaviors can modulate group creativity should open promising research avenues in understanding joint creative actions at large. Ethical approval and consent. Ethical approval for this study was obtained at INSEAD/ Sorbonne University Center for Behavioural Science, Paris, France. All methods were carried out in accordance with their guidelines and regulations. All participants signed an informed consent.

Table 1 below

 1 , this interaction did not concern the linear and quadratic terms of power of familiarity (it actually concerned the sixth order term) and it is thus uninterpretable in this context.

	Variables	Model comparison (ANOVA) Model χ 2 p	Effect	Linear Mixed Models Estimate SE t	df	p
		m1	6.56	0.010 *	co-presence	0.099	0.037	2.65	54.8	0.011 *
	distance				familiarity	-0.023	0.074	-0.31	22.0	0.076
	to "with"	m2	6.89	0.331	familiarity 2	0.166	0.073	2.28	21.7	0.033
		m3	5.72	0.456	interaction	0.052	0.104	0.50	56.0	0.621
	distance	m1	7.17	0.007 **	co-presence	-0.084	0.031	-2.74	49.9	0.008 **
	to "against"	m2	7.80	0.253	familiarity familiarity 2	0.051 -0.113	0.058 0.056	0.88 -2.01	19.4 19.1	0.391 0.059
		m3	10.6	0.100	interaction	-0.016	0.081	-0.19	53.5	0.848
	distance	m1	1.94	0.164	co-presence	-0.041	0.028	-1.43	49.4	0.160
	to "without"	m2	5.63	0.467	familiarity familiarity 2	-0.035 -0.066	0.066 0.064	-0.54 -1.02	21.7 21.5	0.597 0.318
		m3	2.25	0.895	interaction	0.037	0.081	0.46	52.1	0.648
		m1	9.74	0.009 **	co-presence	-0.106	0.039	-2.71	51.3	0.009 **
	time in				familiarity	0.063	0.080	0.78	21.5	0.442
	"with"	m2	6.16	0.405	familiarity 2	-0.163	0.079	-2.06	21.2	0.052
		m3	6.44	0.376	interaction	-0.042	0.107	-0.40	55.6	0.694

Table 1 .

 1 Comparison of models and coefficient of regression testing the effects of familiarity and co-presence

	for different variables. Models m1, m2, m3 refer to the nested models described above. * indicates significance
	with p < 0.05, ** p < 0.01; *** p < 0.001.

The remaining graphs cans be found here: https://archive.org/details/synoptic_graphs.

This work was funded by ANR MICA (ANR-17-CE27-0021, to C.C.). The authors thank all the musicians who participated in the study, as well as Jérémie Bourgogne and Orian Arachart for recording the sessions.


Otto Rottier
email: ottorottier@gmail.com

Benjamin Matuszewski
email: benjamin.matuszewski@ircam.fr

A Rust Implementation of the Web Audio API Decoupling the Web Audio API from the web

Keywords: •Applied computing → Sound and music computing, •Software and its engineering → Software libraries and repositories, •Information systems → World Wide Web, Web Audio API, Rust

In this paper we present a novel implementation of the Web Audio API specification written in Rust. While still in its early stage, the library already proposes a stabilized API and an important subset of the specification. We think this novel implementation has the potential to fill two complementary gaps. From a Web Audio API perspective, it proposes to decouple the API from the web (and web browsers), potentially opening new application areas and helping to widen its community of users. From a Rust perspective, it could provide an intermediary and extensible solution for audio applications that is not yet available in the ecosystem. This paper describes the general design of the library, expliciting and justifying the trade-offs that have been made to the specification in regards to the specificities of the Rust language. This general picture is completed with some examples of usage of the library and a discussion on its current performance. Additionally, a related JavaScript package that proposes Node.js bindings to the core Rust library is introduced. The project is open-source and released under the MIT License.

INTRODUCTION

In the last decade, the Web Audio API first proposed by Chris Rogers in 2011 and released as a W3C Recommendation in 2021 [START_REF]Web Audio API Specification[END_REF], has gained increasing attention by developers, artists and researchers. Indeed the possibility of doing advanced audio processing and synthesis natively on the Web platform has unfolded a number of novel possibilities in different domains such as music performance and creation, gaming or online conferencing. As of today, the Web Audio API appears to have reached a point where its growing community of users, number of existing applications and amount of documentation and tutorials makes it an interesting alternative for someone willing to develop an audio application. Despite this interest and the large application domains, we believe adoption of the Web Audio API is limited by the sandboxed and constrained environments that are Web browsers. With its stable specification and comprehensive documentation, the Web Audio API could offer an interesting alternative for native applications. In this paper we present web-audio-api-rs1 , a novel implementation of the Web Audio API written in the Rust language [START_REF] Matsakis | The rust language[END_REF] that we think could fill this gap.

The choice of the Rust language has been motivated by several reasons. Primarily, Rust is a low-level, memory-efficient language much like C++. There is no runtime and no garbage collector which means we can build real-time audio components with predictive timing and high performance. Unlike higher level languages such as Python or JavaScript, Rust allows us to use memory efficient primitives (float, double, atomic, reference-counted etc), to choose between stack and heap allocation and to define custom memory allocators. Compared to C++, Rust introduces the concept of data ownership which prevents the entire class of race conditions and concurrency issues that may arise in multi-threaded execution. This gives us two advantages when implementing audio systems: we can eliminate some needless copies of audio buffers and it gives us a compile-time guarantee that the concurrent execution of the control thread and render thread is free of data races. Moreover, the Rust ecosystem (compiler toolchain, dependency management, error messages, auto-generated documentation) is modern, easy-to-use and beginner-friendly, potentially opening the domain of low level audio processing to developers that are primarily invested in web programming [START_REF]JetBrains -the state of developer ecosystem 2021 -rust[END_REF]. As such, our project also welcomes contributors that are well versed in using the Web Audio API and want to get their hands dirty in low level audio processing.

Beyond the personal learning experience of implementing such an API from scratch, our objectives for the library are twofold. First, we aim for full compliance with the specification and, for deviating from it only in specific, justified and therefore predictable cases. Second, and deriving from this first point, our goal is to provide an API that is both easy to use when coming from a JavaScript background with only a few adaptations to the Rust coding style and specificities, and inversely, can leverage on existing JavaScript documentation and tutorials for Rust users. As such, the library could open interesting perspectives in several application domains. In artistic contexts, it could open novel possibilities in several areas such as distributed music systems or digital musical instruments (DMI). For start-ups and industry, it could provide a novel tool to support the path from prototyping to production (e.g. simple prototyping in JavaScript easily ported to Rust for performance) in many domains such as game development or embedded devices creation.

After a presentation of the related works (Section 2), we will present in Section 3 the main design and implementation aspects of the library. This general presentation will be followed in Section 4 by a few examples of its usage and by a discussion about its performances in Section 5. Finally, we will introduce in Section 6 a related JavaScript package that provides Node.js bindings to the core library.

RELATED WORKS

Few attempts have been made over the years to implement the Web Audio API as an autonomous library that could be used outside Web browsers. For example, the LabSound project [7] proposes an open-source C++ library originally forked from the Webkit implementation. However, while the library appears to be maintained, the authors state themselves in the README of the project that they do not aim at maintaining full compatibility with the specification. Furthermore, they state that "LabSound has deliberately deviated from the spec for performance or API usability reasons", which is "expected to continue into the future as new functionality is added to the engine." Derived from this project, the node-audio library [8] proposed Node.js bindings built on top of Labsound. However, the project is presented by its author as in an "extremely experimental state" and does not seem to be maintained (i.e. last commit 4 years ago).

The web-audio-engine project [13] proposed an alternative approach by proposing an implementation of the Web Audio API written in pure JavaScript, and could therefore be used within Node.js applications. Despite this amusing and didactical approach, the project is obviously tied to the threading limitations of JavaScript and could not have reached any serious performance comparison with low-level implementations. Additionally, the project has been archived by its author and will not receive any further support.

Finally, we can cite the servo-media component [9] created in the context of the Servo project backed-up by Mozilla and implemented in Rust. While much larger in scope, the library proposed a low-level implementation of the Web Audio API. However, we can observe that the public API differs in many regards with the JavaScript API, preventing reuse of acquired knowledge or to easily port code from one language to the other. Additionally, since the abandonment of the Servo project by Mozilla in August 2020, the library appears unmaintained and hasn't received any updates.

In the growing Rust ecosystem, a number of audio libraries with different scopes and goals have also been proposed. For example, the dasp project [3] offers a number of components that provide low-level abstractions for working with digital audio signals. Inside this suite, the dasp-graph component aims at creating modular and dynamic audio graphs. However, the component is very general purpose and low-level, and does not provide higher-level building blocks as in the Web Audio API.

On the other side of the spectrum, the Kira project [START_REF]Kira -expressive audio library for games[END_REF] provides a high-level "audio library designed to help create expressive audio for games". The library appears to be well maintained and is even recommended as a community plugin alternative for the Bevy game engine. However, this focus on game development also means the library may be not suited for more general purpose audio processing such as the Web Audio API.

Inside this frame, we consider that our library has therefore the potential of filling two gaps. First, from a Web Audio API perspective, it provides a native solution decoupled from Web browsers, potentially opening new application areas and helping to widen its community of users. Second, from a Rust perspective, it proposes an intermediary and extensible solution for advanced audio applications that is not yet available in the ecosystem.

DESIGN & IMPLEMENTATION

On multi-core processor systems, dynamic audio libraries typically split up work between a control thread and a render thread. This approach can be seen as a variation of the client / server architecture widely implemented in computer music oriented languages and platforms [START_REF] Déchelle | jMax: An Environment for Real-Time Musical Applications[END_REF][START_REF] Mccartney | Rethinking the Computer Music Language: SuperCollider[END_REF][START_REF] Puckette | FTS: A Real-time Monitor for Multiprocessor Music Synthesis[END_REF]. The Web Audio API, constrained also by the specifics of the JavaScript language, makes no exception and requires the implementation of this pattern 2 . In such an architecture, the render thread has the sole responsibility of rendering the audio graph and shipping the samples to the OS so they can be played by the hardware. This thread therefore has hard real-time constraints: if it is unable to serve up the next block of audio samples in time (128 in the case of the Web Audio API), users will hear catastrophic clicks and pops. The control thread on the other hand, is user-facing and orchestrates all changes to the audio graph. It allows the user of the library to add and remove nodes and change their settings. Additionally, other threads can be spawned to handle tasks that could block the control thread for too long. For example, the specification requires a media decoder3 thread. Our implementation follows this model and uses lock-free message passing for cross thread communication.

It is important to realize that the objects we colloquially call audio nodes are distinct from the objects that are placed inside the render thread, which we call audio processors. As in figure 1, the audio node and the audio processor are therefore always created as a pair.

AudioNode

User facing object that implements the AudioNode interface from the W3C spec. It does not perform any audio processing, but allows the user to mutate the audio graph, by adding or removing connections or changing the settings of its related AudioProcessor.

AudioProcessor

Object that is placed on the render thread, which produces the actual audio frames. It cannot be directly manipulated by the user and relies on instructions received from its corresponding AudioNode to change its own behavior.

Control thread

On the control thread, audio nodes are created, mutated and (dis-)connected. Method calls on the audio context, audio nodes or audio params typically spin off a control message to be handled by the render thread. Hence these methods operate synchronously and do not block, they are therefore safe to use on a UI thread.

In our implementation, following both the specification and the JavaScript behavior, an AudioNode can go out of scope (i.e. to Drop in Rust idiom) in the control thread, while its processing counterpart continues to run inside the render thread. In such a case, the renderer will be released only when it has finished processing (governed by the tailTime behavior). On the contrary, if the AudioContext itself is dropped in the control thread, the corresponding render thread is immediately halted and all resources are released.

Render thread

Our implementation makes use of the cpal library [START_REF]CPAL -Cross-Platform Audio Library[END_REF] as the audio backend. This library will set up a real-time high priority OS thread to collect the audio samples. This is the thread in which the AudioProcessors run. The entry point of cpal is a callback that expects us to fill an array of float or integer interleaved audio samples (i.e. a FnMut(&mut [f32|u16|i16]) in Rust idiom). While the desired size of the output array can be specified (e.g. 128 samples per channel in the Web Audio API specification), in practice this value is not always available or allowed by the underlying system. In such case we still render the audio graph piecewise in blocks of 128 samples (maintaining therefore the accuracy and regularity of the audio time), but perform internal buffering to align the buffer sizes. For example, if the cpal callback data size is 192, two buffers of size 128 will be rendered on one over two cpal calls.

The AudioGraph is responsible to store the AudioProcessors and to ensure that they are rendered in the right order by performing a topological sort of the audio nodes as defined in the specification 4 . This algorithm ensures that when node A has an outgoing connection to node B, the processor of A is called before B. Therefore, when A has rendered, its resulting samples are copied and mixed appropriately to serve as input for processor B. Each time a node is added or removed from the graph, or when the connections between them are altered, the previous ordering is cleared and recalculated. Additionally, during this topological sort, a cycle detection is performed to mute every node that is part of the cycle unless a DelayNode is present. To implement the dynamic lifetime of the audio nodes described in Sec. 3.1, the AudioGraph will also keep track of the processors that have finished their rendering and will consequently clean up branches of the audio graph that will no longer emit output.

The design of the AudioProcessor interface is very much inspired by the AudioWorkletProcessor interface as defined in the specification [START_REF] Choi | AudioWorklet: The future of web audio[END_REF]. An AudioProcessor is therefore a stateful object that will execute on every render tick a callback of the following form: The AudioRenderQuantum type is a specialized container type for the sample frames, which uses fixed sized, reference counted arrays with copy on write semantics. This allows for very efficient implementation of up/down-mixing, fan-in/out of channels and, in a general way, for moving input and output buffers around without making copies and allocating memory.

The RenderScope reference is modeled after the specification of the AudioWorkletGlobalScope. It contains the current time, sample frame and sample rate, and in the future it will allow processors to share code and data (such as a wavetable or impulse response) within the render thread.

Message passing

A single, asynchronous communication channel is established from the control thread to the render thread. Following the Web Audio API specification, this is called the control message queue. The queue is a FIFO queue where items are ordered by time of insertion, the oldest message being at the front of the queue. The reason a single message bus is used instead of multiple ones, for example from every node to its corresponding processor, is to ensure that audio graph updates cannot be applied out of order. This is best shown with an example: // create a new Oscil latorNod e let osc = c o n t e x t . c r e a t e _ o s c i l l a t o r () ; // set the frequency to 500 Hz ( mutate renderer ) osc.frequency () . set_value (500.) ; // connect oscillator to destination ( mutate graph ) osc.connect (& c o n t e x t . d e s t i n a t i o n ) ;

We can see here that if the audio graph topology messages are handled out of order with the audio node processor setting messages, it could be possible for the OscillatorNode to play at the wrong frequency (i.e. 440 Hz) for a single render quantum.

Tradeoffs Between Spec and Language

While an important goal for our library is to adhere to the specification as much as possible, some differences are impossible to avoid in translating an API targeted at JavaScript to Rust. The most obvious deviations are that we chose to 1. implement all AudioNodes in a thread-safe way and 2. to conform to the Rust code style standard, which enforce the use of snake_case for methods and of CamelCase for enum variants. 5 The most important differences lie in the implementation of some object-oriented programming concepts, which are very common in the specification but that are not supported by the language. First, Rust does not allow us to override property getters and setters. Therefore, instead of directly exposing the AudioBufferSourceNode::buffer attribute, we offer two methods: AudioBufferSourceNode::buffer() -> AudioBuffer and AudioBufferSourceNode::set_buffer(buffer: AudioBuffer) 6 . Second, Rust is strongly designed toward composition rather than inheritance. Therefore to model inheritance, we decided to use Traits for parent / extendable interfaces such as AudioNode, AudioScheduledSourceNode or BaseAudioContext.

For dictionaries, we decided to use composition of Structs to model inheritance, for example for the AudioNodeOptions. Third, Rust does not provide any mechanism for method overloading. In such cases, rather than providing a single method with Option parameters, we chose to expose several specialized methods. For example AudioScheduledSourceNode::start([time]) is derived as start() and start_at(time: f64).

A concept that is very specific to Rust is the concept of data ownership. Ownership is a mechanism to prevent concurrency bugs and data races that is enforced at compile time so there is no runtime overhead. This means we can avoid needless copies of data because the language can guarantee us we have a non-aliased, mutable reference of data. For example, the AudioBufferSourceNode takes an AudioBuffer by value so we do not need to implement the idea of "acquiring the content" as described in the specification 7 . Of course, it is still possible to reference and reuse an AudioBuffer but the user needs to be explicit and clone the data before feeding it into the source node. Note that such clones are generally cheap in terms of memory because the buffers are reference counted containers implementing a copy-on-write semantics, and will therefore be lazily copied only if mutated through copyToChannel.

Finally, the Web Audio API is relatively isolated from other web standards which makes it quite simple to decouple it from the Web. However, this does not hold for some nodes such as the MediaStreamAudioSourceNode (input) or the MediaStreamAudioDestinationNode (output) nodes. We consider these I/O possibilities to be essential for building rich apps such as video conferencing or online gaming. Therefore, we tried to come up with an API boundary interface as simple and flexible as possible to tackle this question, and hence modeled the media streams as a Rust style iterator of fallible buffer items: the MediaStream trait. 5 Fortunately, the search function of the auto-generated documentation is not sensitive to these discrepancies, meaning users should have no issue in finding the right spelling of a method or enum. 6 Some attribute names such as type and loop are reserved keyword in Rust, in these cases we decided to append an underscore to the getter, e.g. OscillatorNode::type_ 7 https://www.w3.org/TR/webaudio/#acquire-the-content

AudioWorklet and Extensibility

The question of extensibility is an important aspect that has been handled in the specification with the introduction of the AudioWorklet interface [START_REF] Choi | AudioWorklet: The future of web audio[END_REF]. Such an interface is required in JavaScript because of the particular nature of the language and of the necessity to run arbitrary code in the high-priority audio thread. In a Rust context, this question is however posed differently as these limitations and constraints do not hold anymore.

As our implementation of audio processors closely resembles the signature of the AudioWorkletProcessor callback (see Section 5.1), we have thus decided to not implement the entirety of the AudioWorklet interface. Instead, we expose our AudioProcessor trait in the public API of our library and users are advised to use it to build their own custom nodes. Over time we may decide to still implement a spec compliant interface for worklets if such a feature appears important for users. However, the performances will remain suboptimal compared to implementing the lower level interface.

Current Known Limitations

Two important concepts of the Web Audio API are currently missing in our implementation: asynchronous functions (methods that return a Promise) and event handling (attributes of type EventHandler).

The Rust equivalent of a function returning a Promise is an async function. The async execution model landed in the core language in 2019 [1]. This opened the possibility for libraries that perform I/O to offer asynchronous versions of their functionality. Users should bring in their own executor of choice (typically tokio [START_REF]Tokio -a runtime for writing reliable asynchronous applications with rust[END_REF]) which will poll the pending I/O operation concurrently. Our implementation currently only offers a synchronous version of the async functions in the specification. Our progress on this point is also dependent on downstream libraries (mainly the media decoder) as they must support asynchronous execution before we can tap into it.

The concept of event handling has no equivalent in the Rust language, so we will have to come up with our own adaptation. Analogous to decisions made regarding the interface of other web standards discussed in 3.4, we will eventually come up with a simplified interface that allows us to hook a callback into the event targets. Event propagation and cancellation are probably not meaningful in our context.

Besides these general questions, a few limitations of our implementation at time of writing are worth mentioning. First, the ConvolverNode and DynamicsCompressorNode are not yet implemented, as well as some important features of the PannerNode such as HRTF support. Second, the OscillatorNode does not fully adhere to the specification: the built-in oscillators are not based on PeriodicWave and only applies rudimentary strategy to prevent aliasing (i.e. polyBLEP). Finally, the DelayNode does not yet allow sub-quantum delays when not in a cycle.

EXAMPLE USE

In this section, we present two examples illustrating the current state of the public API and some possibilities already offered by the library 8 .

Feedback Delay

The example in Figure 2 shows a simple implementation of a feedback delay implemented with our library. The example also highlights different automation methods of the AudioParam, as well as the use of the scheduling methods of the AudioScheduledSourceNode interface.

Granular Scrub

The example in Figure 3 presents a scrubbing effect realized using a granular synthesis approach. The example also shows how a given File can be decoded into an AudioBuffer that is then consumed by AudioBufferSourceNodes scheduled to read back and forth the AudioBuffer at half speed.

PERFORMANCE

Audio processing systems typically face hard real-time constraints: when the production of new sample frames lags behind the actual playback, users will be faced with catastrophic clicks and pops. Therefore the performance of the render thread must be optimized. If the overhead of the audio processing library is low, users can build richer audio graphs without running into issues. The performance of the control thread operations is of lesser concern because it will have no influence on audio playback. UI thread operations should never take more than a few milliseconds though.

The web-audio-api-rs library currently has not been profiled for performance extensively. Some initial results are presented in this section but we expect them to change significantly over time.

Render Thread Considerations

So far we have invested in three classes of performance optimizations.

The first and foremost goal is to prevent allocator calls in the render loop by reusing heap allocated objects. Allocator calls in Rust acquire a program-wide lock on the system allocator and are unpredictable in their timing, especially in contended use cases. To deal with this, we have built a custom allocator on top of the default Rust allocator in order to reuse channel sample vectors as they propagate through the audio graph. More work is still to be done: whenever nodes are added or removed, or audio param automation events are handled, (de)allocations may still occur. Eventually we will add . set_value (0.)

19

. s e t _ v a l u e _ a t _ t i m e (0. , start_time ) 20

. l i n e a r _ r a m p _ t o _ v a l u e _ a t _ t i m e (1. , start_time + duration / 2.)

21

. l i n e a r _ r a m p _ t o _ v a l u e _ a t _ t i m e (0. , start_time + duration ) ; a constructor for the AudioContext that can specify its required capacity upfront and will run guaranteed allocation-free.

Second we avoid operations that block, such as acquiring a lock on a mutex. When high-priority render thread blocks on a resource that is held by a lower priority thread, priority inversion [START_REF] Kacur | Realtime kernel for audio and visual application[END_REF] may occur on some systems. This will lead to non permissible delays in producing the next sample frames. Instead of utilizing mutexes to share state between threads, we use lock-free message passing and atomic primitive types (e.g. AtomicU64).

Last, we attempt to write all audio processor code in such a way that the compiler can apply auto-vectorization of transformations of the sample vectors. This means that the following simplified snippet for applying a volume gain will be compiled to SIMD instructions: We can verify this optimization takes place with the Godbolt compiler explorer using the right optimization flags (-C opt-level=3 -C target-cpu=native) [START_REF]Godbolt compiler explorer -simd optimization[END_REF]. We are also working on an optimization that detects if all channels in an audio buffer are equal. This is very common in Web Audio API programs because the default behavior of almost all nodes is to upmix their input to a 2-channel speaker output. For example, when a mono signal is fed to a GainNode with default settings, the mono signal will be upmixed to stereo and the gain will be applied to both identical channels. In our implementation, upmixed buffers will only apply the transformation once.

pub

Benchmarks

To evaluate current performances of the library, we ported the benchmarks developped by P. Adenot from [START_REF]webaudio-benchmark[END_REF] into Rust. The main idea of these benchmarks is to calculate an AudioBuffer (generally of 120 seconds) using an OfflineAudioContext, measure the time needed to calculate the buffer (i.e. between the start and the end of the rendering) and compare this value to the duration of the buffer, giving therefore an estimation of the performances according to real-time. From the available benchmarks, we could port all of them except the one regarding the ConvolverNode which is not yet implemented in our library. We consider this approach interesting as it should minimize the JavaScript overhead in browsers and therefore allow us to almost compare against the bare-bone C++ implementations.

The benchmarks have been run on two different computers: a MacBook Pro 2019 with a 2,3 GHz 8-Core Intel Core i9 processor and 16 GB of 2400 MHz DDR4 RAM, and a MacBook Pro 2020 with a Apple M1 processor (ARM) and 8 GB of LPDDR4X-4266 MHz RAM. For each tested platform (Google Chrome, Firefox, and our library) the benchmarks have been run 5 times. Reported results are the mean of these 5 runs and are the speed-up compared to real-time (i.e. duration/processingT ime), so the higher the better.

As shown in the results presented in Table 1 and 2 in the appendix, we can consider that our library has room for improvement compared to these state of the art implementations, but is not completely out of the game: 2.8 slower than Chrome and 5,7 times slower than Firefox on the MacBook Pro 2019.

We think these results, while not completely fair for all cases (see in particular Section 3.6) are quite encouraging, especially considering that our work so far has been focused on compliance and API stabilization rather than performance. Moreover, while developing the library we have not heavily studied the source code of the Firefox and Chrome implementations. These implementations have been optimized for years and will allow us to cherry pick relevant improvements, such as node pre-assignment and pooling, for our own codebase.

NODE.JS BINDINGS

In this section, we present node-web-audio-api-rs 9 , a related npm package that provides Node.js bindings to web-audio-api-rs. We present first the general goals and the technical approach we followed, and then illustrate its usage with an example. The library is still in its early developments and does not yet cover all the features implemented in web-audio-api-rs.

General Approach and Goals

Our main goal in developing this bindings is to propose a perspective we could call Isomorphic Web Audio. We believe such an approach could prove to be interesting contribution in several areas such as distributed music systems [START_REF] Matuszewski | Toward a Web of Audio Things[END_REF] or more generally for the field of Internet of Musical Things [START_REF] Turchet | Internet of Musical Things: Vision and Challenges[END_REF]. Indeed, it could allow to seamlessly develop JavaScript audio components able to run both in the browser and on headless nano-computers such as the Raspberry PI. Another potential of the package is to enable the testing of 9 https://github.com/b-ma/node-web-audio-api-rs the core web-audio-api-rs library against the official Web Audio test suite [START_REF]The web-platform-tests project -webaudio[END_REF], therefore contributing back to its development and compliance.

The package is build using napi-rs10 , which propose Rust to Node-API bindings, and should therefore garantuee forward compatibility with Node.js. The approach we choose to follow is to derive and generate most of bindings code from specification IDL, using JavaScript as a parser and a template engine for the Rust code. While still in its early stage of development, we hope this approach will help to maintain the package up-to-date according to the core library. Finally, we took care of hiding the specifities of the Rust API described in Section 3.4 to provide an interface that is exactly similar to the one exposed in Web browser. Such an approach could, at least in theory, allow to simply reuse a whole set of existing higher-level libraries [START_REF] Schnell | Of Time Engines and Masters An API for Scheduling and Synchronizing the Generation and Playback of Event Sequences and Media Streams for the Web Audio API[END_REF] [19] in a Node.js context. The example code in Figure 4 shows the granular scrub example presented in Section 4.2, rewritten back in JavaScript. The example also highlights how an existing component, i.e. the lookahead Scheduler provided by the waves-masters library [START_REF]waves-masters -low level components for transport and scheduling[END_REF], can be simply reused in this context.

Example Use

CONCLUSION

In this paper we have presented web-audio-api-rs, a novel implementation of the Web Audio API specification implemented in the Rust language. We first described the general design of the library, expliciting and justifying the trade-offs that have been made to the specification in regards to the specificities of the Rust language. We then completed this general presentation with some examples and a picture of its current performance. Finally, we introduced a related JavaScript package that proposes Node.js bindings to the core library.

While still in its early stage, the library already proposes a stabilized API and implements an important subset of the specification. We think this novel implementation has the potential to provide an interesting solution in several directions: open new application areas for the Web Audio API community by decoupling the library from the Web, and provide an intermediary and extensible solution for audio applications that is not yet available in the Rust ecosystem. We hope that future evolutions of the library, backed by new and diverse contributors, will allow us to mitigate the limitations described in this paper and offer a worthy alternative to the inbrowser implementations.

  Licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0). Attribution: owner/author(s).Web Audio Conference WAC-2022, July 6-8, 2022, Cannes, France.

©

  2022 Copyright held by the owner/author(s).

Figure 1 :

 1 Figure1: Architecture of the library, showing the components living in the control thread (audio nodes and the audio context) and components that live in the render thread (the audio graph and the audio processors).

  c a l l b a c k A u d i o W o r k l e t P r o c e s s C a l l b a c k = boolean ( FrozenArray < FrozenArray < Float32Array > > inputs , FrozenArray < FrozenArray < Float32Array > > outputs , object parameters ) ; Here, inputs[n][m] and outputs[n][m] follow a planar layout where arrays of audio samples are stored in the mth channel of the nth input or output. The parameters object contains the computed values for each AudioParam of the AudioProcessor for this rendering quantum. The return value corresponds to the tailTime behavior, which allows the AudioProcessor to be dropped by the AudioGraph when it has finished rendering (i.e. when returning false) and has no input connections. In our Rust implementation, this IDL has been adapted to: fn process ( & mut self , inputs: &[ A u d i o R e n d e r Q u a n t u m ] , outputs: & mut [ A u d i o R e n d e r Q u a n t u m ] , params: AudioParamValues , scope: & RenderScope , ) -> bool;

1

  use std::fs ::File; 2 use std:: { thread , time }; 3 use w e b _ a u d i o _ a p i : : b u f f e r : : A u d i o B u f f e r ; 4 use w e b _ a u d i o _ a p i : : c o n t e x t : : { AudioContext , B a s e A u d i o C o n te x t }; 5 use w e b _ a u d i o _ a p i : : n o d e : : { AudioNode , A u d i o S c h e d u l e d S o u r c e N o d

22 23 let

 23 src = a u d i o _ c o n t e x t . c r e a t e _ b u f f e r _ s o u r c e () ; 24 src. set_buff er ( a u d i o _ b u f f e r . c l o n e () ) ; 25 src.

1

  const path = require ( path ) ; 2 const { Scheduler } = require ( waves -masters ) ; 3 const { AudioContext , load } = require ( node -web -audio -api -rs ) ; 4 5 const audioContext = new AudioContext () ; 6 const scheduler = new Scheduler (() = > a u d i o C o n t e x t . c u r r e n t T i m e ) ; 7 const file = load ( path.join ( __dirname , sample.wav ) ) ; 8 const buffer = a u d i o C o n t e x t . d e c o d e A u d i o D a t a ( file ) ; 9 10 const period = 0.05; 11 const duration = 0.2; 12 let incr = period / 2; 13 let position = 0; > b uf fe r .d ur at i on -2 * duration || 19 position a u d i o C o n t e x t . c r e a t e G a i n () ; 25 env.connect ( a u d i o C o n t e x t . d e s t i n a t i o n ) ; 26 env.g ain.valu e = 0; 27 e n v . g a i n . s e t V a l u e A t T i m e (0 , currentTime ) ; 28 e n v . g a i n . l i n e a r R a m p T o V a l u e A t T i m e (1 , currentTime + duration / 2) ; 29 e n v . g a i n . l i n e a r R a m p T o V a l u e A t T i m e (0 , currentTime + duration ) ; 30 31 const src = a u d i o C o n t e x t . c r e a t e B u f f e r S o u r c e () ; 32 src.connect ( env ) ; 33 s r c . d e t u n e . v al u e = Math.random () *

Figure 4 :

 4 Figure 4: Example code of the granular scrub example rewritten back to JavaScript.

https://github.com/orottier/web-audio-api-rs

https://www.w3.org/TR/webaudio/#control-thread-and-rendering-thread

https://www.w3.org/TR/webaudio/#dom-baseaudiocontext-decoding-thread

https://www.w3.org/TR/webaudio/#rendering-loop. Note that there are subtle differences in our implementation because we are storing edge information in a different way. The resulting sort order conforms to the specification though.

https://napi.rs/

ACKNOWLEDGMENTS

We would like to thank our contributors, especially Jerboas86 for his precious contributions to the project. We would also like to thank our colleagues at IRCAM for their support on this project.

APPENDIX

Benchmark

Chrome Firefox Rust Empty testcase