Dylann Batisse

Antoine Cousson

Antoine Vidal Mazuy

Jean-Philippe Carlens

Michel Buffa

Host and Plugins : Parameter Automation Without Crossing the Audio Thread Barrier

WebAudio Modules 2.0 (aka WAM) is a standard for developing interoperable host and plugins that can be written using different development approaches (JavaScript, build systems, TypeScript, FAUST, Csound, front-end frameworks, etc.). The WAM standard has been designed with high performance host-plugin communication in mind when both the host and plugins are running in the audio thread. This is the case when the host is written as an Audio Worklet (AW) and when plugins are also AW based. We have developed for the WAM standard an example of such a host: a very simple DAW using Audio Worklets to manage the audio buffers for each track. In a typical way, each track is associated to a chain of plugins, to bring for example real time effects on the signal. This DAW is an interesting example to study for developers who would like to write this type of program: not only does it show how to manage audio buffers with sample accuracy (in order to have very precise loops), but it also shows how, thanks to the tools offered by the WAM standard, you can automate a large number of plugin parameters at the sample rate in a very efficient way (using Shared Array Buffers and Ring Buffers), much more than what is possible with the management of the parameters offered by the WebAudio API.

Introduction

In 2015 Jari Kleimola and Oliver Larkin created Web Audio Modules (WAM) [START_REF] Kleimola | Web audio modules. 12th Sound and Music Computing Conference (SMC15)[END_REF], a standard for creating reusable and interoperable plugins implemented as WebComponents, the core of which was written in C/C++. This initiative was aimed primarily at developers of native plugins (i.e. VST plugins). Since then, this standard has evolved in a new "Web Audio Modules 2.0" version [START_REF] Buffa | Web Audio Modules 2.0, an open Web Audio plugin standard[END_REF], taking into account feedback from developers of the first version and the evolution of web standards (with WebAssembly, WebComponents, WebMidi etc.). The WAM distribution is open source and distributed as four GitHub repositories and as npm modules (MIT License) 1. One of these repository, the wam-example github repository, contains different plugins and hosts that cover a variety of programming languages and approaches. WAM v2.0 creators asked us to develop some host examples written as AudioWorklets (AW), with and without the use of WebAssembly modules, to show some features of the standard, in particular how WAM events can be used to automate a large amount of plugin parameters without leaving the audio thread (this is the case when both the host and plugins are written as AW running in the audio thread).

WebAudio API limitations for parameter handling

Since the WAM standard aims to allow maximum flexibility for developers, WAM authors have decided that WebAudio API's AudioParams should not appear explicitly in the WAM API. Some WAM design patterns do not make use of any stock WebAudio API nodes, and while it is possible to define custom parameters for AudioWorklet, in many cases it would be too heavy / cumbersome to expose the potentially hundreds of parameters residing in WebAssembly code via that API. Furthermore, the parts of the WebAudio API having to do with parameters were conceived before developers had any direct access to the audio thread, forcing parameter updates to be scheduled asynchronously from the main thread far enough in advance to account for crossing the thread barrier. This aspect of the WebAudio API is not compatible with the goal to support synchronous, 'just in time' interaction between hosts and plugins on the audio thread as in native plugin environments. To get around these limitations the WAM standard has its own WamParameter API to handle parameter updates, designed to facilitate many different WAM design patterns and interaction between hosts and plugins on either thread.

Plugin parameters and host-plugin communication

Sample-accurate event scheduling is a critical requirement for professional audio applications. The WebAudio API does allow for sample-accurate scheduling of AudioParams, and this capability is leveraged in the WAM SDK to facilitate WAMs that incorporate one or more stock Web Audio nodes. However, as mentioned before the automation API for AudioParams is not useful for many WAM design patterns, and we wanted to show how WAM supports sample-accurate processing of other kinds of events such as MIDI messages or parameter automation messages. The WAM API facilitates event scheduling through a unified interface that is mirrored on both the main thread and audio thread. Hosts operating entirely on the main thread will still be required to schedule events with some lookahead to ensure that they are processed at the intended time, as these messages must still cross the thread barrier. However, hosts with a presence on the audio thread can schedule events at the beginning of the rendering block in which the events should occur. This is the case of the DAW we will demo.

Related works

At the time of writing (April 2022) the most advanced DAWS available on the Web platform are commercial. The oldest one, oundtrap.com belongs to Spotify, and is mainly based on high level WebAudio API nodes, and is not open to third-party plugins. The same code base seems to be used for a mobile version. Bandlab.com belongs to an Asian company that sells music gear on the Web, and is also available on mobile devices. The technology used is not public, but it seems that the mobile version and the Web version do not share the same code base. AmpedStudio.com uses AudioWorklet and C++ cross compiled plugins a lot, and does not have yet a specific version for mobile devices…It supports different sorts of plugins, including the WAM standard. We have been working with a developer's version of AmpedStudio and managed to load successfully some WAM 2.0 plugins in it. All these DAWs support audio and MIDI tracks, plugin chains for instruments and effects, automation, and some of them are collaborative.

Sequencer.party is a mix between Ableton Live and Google Docs, it's a sequencer 100% collaborative. The sequencer itself is a WAM host and most modules are WAM2 plugins, also available on GitHub.

Gridsound is a more traditional open source DAW, that has been developed since 2015. It supports audio and MIDI, but does not yet supports an interoperable plugin format. It is based on "components" whose format is specific to Gridsound.

There are also popular JS librairies for developing a multitrack player/recorder, such as wavesurfer.js2 or waveform-playlist 3 , and some audacity like audio buffer editors such as AudioMass 4 .

None of the open source DAWs have their core audio player based on AudioWorklet, and only AmpedStudio.com takes care about the audio thread isolation optimization for host-plugins communications. This is why our prototype can be a good way to see how to implement such features.

Settings for the demo

Our host can record/play/edit different tracks with a customizable plugin chain associated to each track. We propose to show some audio projects we prepared, that use a large number of plugins and parameters with automation. During the demo, attendees will also be able create projects from scratch and / or edit existing projects.

We also propose to show some source code extracts and explain how this DAW uses the features of the WAM2 standard for hostplugins interaction (discovering/managing plugins and automation curves, etc.).

6.

https://github.com/webaudiomodules and https://www.npmjs.com/settings/webaudiomodules/packages

https://wavesurfer-js.org/


Marion Croisy
email: marion.croisy@st.com

Cécile Jenny
email: bcecile.jenny@st.com

Claire Richard
email: cclaire-therese.richard@st.com

Denis Guiheux
email: denis.guiheux@st.com

Alain Campo
email: ealain.campo@cea.fr

Erwine Pargon
email: ferwine.pargon@cea.fr

Nicolas Possémé
email: gnicolas.posseme@cea.fr

Characterization and Development of High Dose Implanted Resist Stripping Processes

Keywords: dry strip, residues, photoresist, implant, crust layer, high dose

With the increase of implantation dose in new technologies, implanted photoresist stripping is even more challenged in terms of efficiency and substrate consumption. In this work, the effect of implantation parameters (energy and implanted specie) on the photoresist modifications are studied and several plasma chemistries are evaluated to remove it. A good removal efficiency with a low substrate consumption has been found with H 2 -based processes especially N 2 H 2 .

Introduction

Stripping of photoresist after High Dose Implantation (HDI) is becoming a critical step with the increase of both implantation acceleration energy and dose. During the implantation, the photoresist surface is exposed to energetic ion bombardment and a modified layer (called "crust") is formed. This crust is difficult to remove by conventional dry strip processes. The main requirements of stripping processes are: to remove completely the photoresist without leaving residues on the surface, to avoid the formation of added defectivity such as blisters, to minimize the consumption and oxidation of underlying materials (Si substrate, epitaxial SiGe) and to avoid dopants loss and redistribution on the implanted areas. N 2 /H 2 and O 2 /N 2 plasmas are commonly used in dry strip processes. O 2 /N 2 is known to achieve a high ashing rate and consume the non-modified photoresist preferentially [1] while non-oxidizing plasmas are less reactive to strip the photoresist but are very efficient to remove the crust [2]. In this paper, we focused on the stripping efficiency of oxidizing and reductive plasma chemistries. First, several characterization techniques have been used to evaluate the physical and chemical modifications induced in the photoresist by the implantation step. The impact of both dopant energy and chemical nature have been investigated. Based on this understanding, several plasma chemistries are investigated for removing the implanted resist properly with no remaining residues and minimal substrate loss.

Experimental set up

In this work, 200nm-thick 248nm photoresist (PR) coated on 300mm wafers and commonly used for Complementary Metal Oxide Semiconductor applications has been exposed to either As or P implantation processes with an energy of 4 or 9 keV and a dose between 1.5 and 2.10 15 atoms/cm². Several characterizations techniques (TEM, ToF-SIMS…) have been used to analyze the physical and chemical modifications of the PR exposed to the implantation process. TEM allows to determine the modified layer thickness and the implantation depth respectively. ToF-SIMS is used to get information on chemical profiles in the implanted PR but also to analyze residues composition. These analyses are performed with an Ion-TOF TOF-SIMS 5 instrument with a dual beam acquisition and detection of the negative ions only. A Bi + beam at 25 kV is used for both analyses, with a 50 x 50 µm² raster. For the implanted PR characterization, a 50µs cycle time is used with a 128 pixels resolution whereas for the residues analysis, the cycle time is 90µs and the resolution 1024 pixels. The sputtering is performed using a Cs (500 eV) beam, with a 300 x 300µm² raster for the photoresist and a 300eV beam with a 300 x 300 µm² raster for the residues . An electron flood gun with -20 V bias is also used to overcome charging problems. Oxidizing and non-oxidizing dry strip processes are developed in Gamma GxT tool (Lam Research) on patterned 300mm wafers. Dry stripping processes efficiency is evaluated by CD-SEM observations on a Hitachi 5001 tool.

Experimental results

Implanted Resist characterization. A methodology has been set up to study the influence of implantation parameters (dopant specie and ions energy) on the PR modifications. TEM analyses on resist blanket wafers allow to determine the modified layer thickness for several implantation conditions (Table 1). An example of TEM picture is presented on Figure 1 and allows to discriminate two distinct areas: the underlying non-modified layer ("bulk") and the crust on the PR surface. For both As and P-implanted PR, the crust thickness depends on the implantation energy. At higher energy, the dopants go deeper into the photoresist which is modified on a thicker layer. On the other hand, the dopant specie (As or P) does not influence the crust thickness. However, XRR measurements (not shown here) show a higher density for the As-implanted photoresist. ToF-SIMS analyses have been performed on As and P-implanted photoresist. Figure 2 presents the depth profiles for an energy of 4 kev. It should be noted that the crust thickness obtained by the ToF-SIMS analyses do not correspond to the thicknesses given by the TEM. Indeed, the depths given in Figure 2 are calibrated considering the sputtering rate of the nonmodified resist which is certainly higher than the sputtering rate of the crust layer. Thus, the crust thickness given by the ToF-SIMS is overestimated. These analyses clearly show that the photoresist is modified on the first 50nm whereas the dopants are located until 100nm. This means that the resist is not modified on the entire implanted depth. Another interesting point is that dopants are present in their oxidized and metallic forms in the crust. ToF-SIMS experiments performed with As and P-implanted resist at an energy of 9kev show similar chemical depth profiles, except for the modified depth which is thicker.

Dry strip process development. The dry strip efficiency is evaluated for the same 200nm-thick photoresist with As and P implantation at both 4 and 9 keV using CD-SEM top-down observations. The results obtained for N 2 /H 2 plasma are presented on Figure 3.

Si

As 4keV

N 2 /H 2 is found to be very efficient to remove As-implanted photoresist for both 4keV and 9keV energies and there is no residues left. On the other hand, little black residues on both implanted and non-implanted areas are observed when the resist is implanted with phosphorus. These black residues have been identified by ToF-SIMS analyses as phosphorus oxides. They are likely coming from the implanted photoresist because they are not observed on the wafer surface after the same process without photoresist.

These results indicate that N 2 /H 2 chemistry is not efficient to remove phosphorus oxides coming from the crust, while we assume that it can eliminate arsenic oxides. However, a SPM-SC1 wet cleaning (SPM 5:1 at 80°C and SC1 1:2:80 at 65°C) following the dry strip process (Figure 4) can remove them completely.

Figure 4 CD-SEM top view observation after N 2 /H 2 dry stripping followed by a SPM-SC1 wet cleaning of P-implanted photoresist at 9keV

Concerning the O 2 /N 2 dry strip chemistry, two kinds of residues are observed for both As and P implantations (Figure 5). Black residues larger but similar to those obtained with N 2 /H 2 plasma are observed as well as small residues present on the non-implanted area previously protected by the photoresist. The black residues have also been analyzed by ToF-SIMS (Figure 6) for P 4keV condition and identified as phosphorus oxides. O 2 /N 2 plasma is not efficient to remove oxidized dopants present in the implanted resist and certainly contributes to the oxidation of the metallic dopants also present. No chemical information could be obtained for the other small residues present on the nonimplanted area but they are likely coming from the crust which is known to be hardly removed by O 2 -based plasma chemistries. After a wet cleaning, the black residues identified as oxidized dopants are efficiently removed for both As and P-implanted resist, but the small residues attributed to the crust layer remain on the non-implanted areas (Figure 7). To evaluate stripping chemistries, the effect on substrates (spacer, Si, epitaxial material like Borondoped SiGe called SiGeB) is also an important parameter which has to be taken into account. Several phenomena are commonly observed: the oxide growth at the surface and the substrate consumption. Table 2 presents the results obtained on Boron-dopped SiGe blanket wafers after N 2 /H 2 and O 2 /N 2 plasma processes. As expected, the oxide growth is higher with the oxidizing plasma. N 2 /H 2 is more promising because of the minimal consumption and oxidation phenomena induced in Boron-dopped SiGe. 8). H 2 -based chemistries show interesting results with no remaining black residues after dry strip process (Figure 8a and 8b) even if some residues remains on the non-implanted area (light area on Figure 8). These residues are likely coming from the crust which was not stripped efficiently even after a wet cleaning. However, He/H 2 is clearly more efficient than Ar/H 2 and the stripping efficiency could be improved for instance by increasing H 2 ratio. Only N 2 O allows to remove the crust properly. Furthermore, for all these O 2 -based chemistries, black residues of phosphorus oxide are seen at the edge of wafer after dry strip. So far, N 2 /H 2 plasma followed by a wet cleaning remains the most efficient dry strip process

Conclusions

The photoresist mask is highly modified by the implantation step. A cross-linked carbon layer depleted with H and O but enriched with As or P dopants is formed on the resist surface. The dopants are present both in their elemental and oxidized forms. Several plasma chemistries have been tested to remove the implanted resist. After dry strip process, two kinds of residues can be observed according to the plasma chemistry used: black residues identified as oxidized dopants which are easily removed by a wet clean and smaller residues attributed to the crust. So far the most efficient dry strip process is N 2 /H 2 plasma but such process can introduce some blister defects. Some alternative chemistries show interesting preliminary results especially N 2 O and He/H 2 and further investigations are ongoing on these chemistries especially to evaluate the sensitivity to blisters.

Figure 2

 2 Figure 2 Tof-SIMS analyses of implanted PR : P 4keV 1.5E15 at/cm² (left), As 4keV 2E15 at/cm² (right) Similar chemical modifications of the PR are observed for both implantations. The first 60nm of the photoresist analyzed by ToF-SIMS correspond to the crust observed in TEM picture and are depleted in O and H and enriched in C and dopants (either As or P).It should be noted that the crust thickness obtained by the ToF-SIMS analyses do not correspond to the thicknesses given by the TEM. Indeed, the depths given in Figure2are calibrated considering the sputtering rate of the nonmodified resist which is certainly higher than the sputtering rate of the crust layer. Thus, the crust thickness given by the ToF-SIMS is overestimated. These analyses clearly show that the photoresist is modified on the first 50nm whereas the dopants are located until 100nm. This means that the resist is not modified on the entire implanted depth. Another interesting point is that dopants are present in their oxidized and metallic forms in the crust. ToF-SIMS experiments performed with As and P-implanted resist at an energy of 9kev show similar chemical depth profiles, except for the modified depth which is thicker.

Figure 3

 3 Figure 3 CD-SEM top view observations after N 2 /H 2 dry strip process with several implantation energies a) As 4keV b) As 9keV c) P 4keV d) P 9keV

Figure 5

 5 Figure 5 CD-SEM top view observations after O 2 /N 2 dry strip process with several implantation energies a) As 4keV b) As 9keV c) P 4keV d) P 9keV

Figure 6

 6 Figure 6 Tof-SIMS 3D view of PO 2 -and PO 3 -residues after O 2 /N 2 dry strip

Figure 7

 7 Figure 7 CD-SEM top view observations after O 2/ N 2 dry strip followed by a SPM-SC1 wet clean a) As 4keV b) As 9keV c) P 4keV d) P 9keV

Figure 8

 8 Figure 8 CD-SEM top view observations after a) He/H 2 b) Ar/H 2 c) N 2 O d) O 2 /He dry strip process of a P-implanted PR (4keV) Remaining crust is also observed for O 2 /He as well as for O 2 /Ar and N 2 /H 2 /O 2 (data not shown). Only N 2 O allows to remove the crust properly. Furthermore, for all these O 2 -based chemistries, black residues of phosphorus oxide are seen at the edge of wafer after dry strip. So far, N 2 /H 2 plasma followed by a wet cleaning remains the most efficient dry strip process

Table 1

 1 TEM analyses: crust thickness depending on implantation parameters

	Implanted specie	Energy (keV)	Crust thickness (nm)
	P	4	7
	P	9	18
	As	4	8
	As	9	17

Figure 1 TEM picture of implanted PR (As 4keV)

Table 2

 2 Ellipsometric thickness measurements of oxide growth and Boron-dopped SiGe consumption with N 2 /H 2 and O 2 /N 2 processes Finally, the comparison between the two commonly used chemistries N 2 /H 2 and O 2 /N 2 indicates that N 2 /H 2 is the most efficient to remove implanted photoresist without consuming substrate like Boron-dopped SiGe. Even if some phosphorous-oxides residues could remain after dry strip process, they are entirely removed by the wet cleaning. With O 2 /N 2 plasma, residues assumed to come from the crust layer are still observed on the non-implanted regions even after a wet cleaning.However, some added defectivity called blisters can be observed after several N 2 /H 2 plasma processes[START_REF]Plasma Etch and Strip in Microtechnology[END_REF]. Other chemistries are thus evaluated to remove implanted photoresist with at least the same efficiency as N 2 /H 2 and without blisters formation. Alternative dry strip chemistries either reductive (He/H 2 or Ar/H 2 ) or oxidizing (N 2 O, O 2 /Ar, O 2 /He) have been investigated with phosphorus implanted at 4keV (Figure

	a	b	c	d
		Oxide growth (A) SiGeB consumption (A)
		N 2 /H 2 12	2
		O 2 /N 2 32	7


M Mounie
email: mounie.m@chu-toulouse.fr

N Costa

A Gaudineau

L Molinier

C Vayssière

H Derumeaux

Michael Mounié

Cost-Effectiveness Analysis of Vaginal Misoprostol versus Dinoprostone Pessary: a large noninferiority RCT in France. Authors

Keywords: Dinoprostone, labor induction, misoprostol, cost-effectiveness analysis, PGE2 pessary, vaginal

The cost-effectiveness of Misoprostol versus PGE2 pessary Synopsis: We have shown disparate cost-effectiveness results between 25-μg vaginal misoprostol versus dinoprostone pessary according to the clinical outcome and the payer perspective.

Introduction

Induction of labor (IOL) is a common procedure, performed for approximately 40% of nulliparous and 30% of multiparous women [START_REF] Laughon | Induction of labor in a contemporary obstetric cohort[END_REF]. It is recommended for women with a medical indication and may be justified after 39 weeks of gestation to improve the safety for mothers as well as infants [START_REF] Rice | Labor induction versus expectant management in low risk nulliparous women[END_REF][START_REF] Marrs | Elective induction at 39 weeks of gestation and the implications of a large multicenter randomized controlled trial[END_REF].

At present, the drug of reference for induction is slow-release dinoprostone (PGE2) [START_REF] Fairclough | Vaginal prostaglandin (PGE2 and PGF2a) for induction of labour at term[END_REF].

In comparison, misoprostol, a synthetic analog of prostaglandin E1 (PGE1) is a less expensive, thermostable and easier-to-use drug. Misoprostol has been in use for several years and the optimal dose and route of administration have been widely studied [START_REF] Wing | A comparison of differing dosing regimens of vaginally administered misoprostol for pre-induction cervical ripening and labour induction[END_REF][START_REF] Wing | A comparison of orally administered misoprostol with vaginally administered misoprostol for cervical ripening and labor induction[END_REF]. Therefore, a low-dose by vaginal (25 μg) route is recommended as a first-line treatment for IOL by the American College of Obstetricians and Gynecologists (ACOG) [START_REF]Induction of labor. ACOG Practice Bulletin No. 107. American College of Obstetricians and Gynecologists[END_REF], the International Federation of Gynecology and Obstetrics [START_REF] Morris | FIGO's updated recommendations for misoprostol used alone in gynecology and obstetrics[END_REF], and the World Health Organization [9]. Economic data comparing vaginal misoprostol and dinoprostone are sparse and are based on extremely small studies. A 2003 RCT compared the efficacy and cost of misoprostol (i.e., 50 μg renewed 6 hours later) to those of dinoprostone (either in a 0.5mg gel renewed 6 hours later or a 10-mg slow-release pessary) and concluded that misoprostol was the most cost-effective strategy [START_REF] Ramsey | Comparative efficacy and cost of the prostaglandin analogs dinoprostone and misoprostol as labor preinduction agents[END_REF]. More recent studies from 2016 and 2017, in the US and Spain respectively, have shown cost saving results in favor of vaginal misoprostol in comparison to dinoprostone [START_REF] Nb Kunzier | A comparison of obstetrical outcomes and costs between misoprostol and dinoprostone for induction of labor[END_REF][START_REF] Duro-Gómez | What can we do to reduce the associated costs in induction of labour of intrauterine growth restriction foetuses at term? A cost-analysis study[END_REF]. Since 2018, misoprostol is no longer reimbursed in France and dinoprostone is the gold standard for IOL management.

The CYTOPRO (CYTOtec® vs PROpess®) trial was designed to test the hypothesis that 25-μg of vaginal misoprostol every four hours would not be inferior to a 10-mg slow-release dinoprostone pessary in terms of Cesarean Delivery (CD) rates. We hypothesized that vaginal misoprostol is cost-effective compared to dinoprostone and since this concerns a large population, it could provide substantial public health savings. The primary objective of this work was to assess the cost-effectiveness of misoprostol compared to dinoprostone using CD rates. In addition, we aim to use Vaginal Delivery rate within 24 hours (VD24) in a secondary analysis.

Methods

Study design and patients

The CYTOPRO trial was an open-label, multicenter, randomized, noninferiority trial conducted from September 2012 to June 2015 in four French centers and aimed to compare the efficacy and safety of intravaginal misoprostol (25 μg) every four hours to a 10-mg slow-release dinoprostone pessary (PGE2) [START_REF] Gaudineau | Induction of Labor at Term With Vaginal Misoprostol or a PGE2 Pessary: a Noninferiority RCT[END_REF]. Participating centers were public centers with two in the Paris area (Bicêtre and Poissy), one in Strasbourg and one in Toulouse, which all belong to the French Obstetrics and Gynecology Research Group. This study was supported by the French Ministry of health and was sponsored by the Toulouse University Hospital Center. Clinical data were prospectively collected while economic data where retrospectively collected using a claims database.

The study population was women aged of 18 years or older with a viable singleton fetus in cephalic presentation, a gestational age of 36 weeks or more, an unfavorable cervix (Bishop score ≤ 5), and ≤ 3 uterine contractions per 10 minutes, as recorded by electronic fetal monitoring (EFM) for 30 minutes on admission for a medically indicated IOL. Non-inclusion criteria included a previous CD, a history of myomectomy, suspected fetal distress on EFM on admission, unexplained bleeding, suspected chorioamnionitis, fetopelvic disproportion, estimated fetal weight > 4500 g, placenta previa, active herpes infection (primary infection or recurrence within 7 days), any known allergy or intolerance to prostaglandin agents, and any contraindication to vaginal delivery. Patients were randomly assigned in a 1:1 ratio using the permuted block method with 20 women per block with sealed envelopes for allocation. Randomization was stratified by center and parity (nulliparous/parous) [START_REF] Gaudineau | Induction of Labor at Term With Vaginal Misoprostol or a PGE2 Pessary: a Noninferiority RCT[END_REF]. After providing the patient with information about the trial when there was a medical indication for IOL, informed consent was requested and provided immediately before IOL.

In the misoprostol arm, the clinical care provider placed a 25-μg capsule in the woman's posterior vaginal fornix, every 4 hours with a maximum of 4 capsules per day. Before each administration, if the fetal heart rate (FHR) was non-reassuring, or if the woman had at least two painful contractions in 10 minutes, the capsule was not placed. In the other arm, the pessary was placed by the healthcare provider in the posterior vaginal fornix until labor started or for a maximum of 24 hours. In cases of non-reassuring FHR or uterine tachysystole, the pessary was removed and replaced after normalization of electronic fetal monitoring if removed within the first 12 hours.

Women in both groups were monitored identically, with a one-hour FHR analysis every 4 hours [START_REF] Gaudineau | Induction of Labor at Term With Vaginal Misoprostol or a PGE2 Pessary: a Noninferiority RCT[END_REF].

Setting and perspective

The economic analysis was performed from the French National Health Insurance (FNHI) perspective and focused on costs associated with inpatient stays. The time horizon of the study was limited to the inpatient stay associated with the delivery. No discount rate was applied. In France, public and private hospital fees are based on Diagnoses Related Group (DRG) rates to which can be added extra charges if applicable (i.e., expensive drugs such as medicines with special constraints which are hospital-reserved drugs and day prices for reanimation or intensive care unit stays) [START_REF] Boudemaghe | Data Resource Profile: The French National Uniform Hospital Discharge Data Set Database (PMSI)[END_REF]. DRGs include medical and paramedical staff fees, institutional costs, and common drugs but access to details is not allowed. Through DRGs, the French health insurance totally reimburses inpatient delivery stays. According to the delivery management parameters (parity, IOL, caesarian, duration) and the occurrence of complications, several DRGs are possible with different rates for both mothers and infants. All the mother-and infant-related DRGs associated with delivery were extracted from the inpatient database and were all considered in the analyses. DRG rates also include the price of medications compared (i.e., misoprostol versus dinoprostone) because they do not belong to additional expensive medication. In the context of the FNHI perspective, the costs of the two drugs studied were not considered. Nevertheless, in France, one slow-release dinoprostone pessary costs €83 ($99) per patient while a misoprostol capsule costs €0.44 ($0.5), at up to four capsules per patient.

Clinical and economic outcomes

Our goal was to estimate the Incremental Cost Effectiveness Ratio (ICER) defined as the mean incremental cost between the misoprostol group and the dinoprostone group divided by the mean incremental effectiveness between the groups. This ratio represents the estimated monetary value required for one unit of effectiveness [START_REF] Drummond | Methods for the Economic Evaluation of Health Care Programmes[END_REF].

The main aim of any obstetrician is a vaginal delivery, with a healthy mother and child. Therefore, comparably, the CD rate is a more relevant outcome than the timing of the delivery which is subsequent [START_REF] Sagi-Dain | Vaginal delivery within 24 hours of labor induction as a primary outcome: what's the rush? Letter to the Editor|[END_REF]. Moreover, the rate of Vaginal Delivery within 24h (VD24) is a useful clinical outcome which also has significant implications with regards to hospital costs and patient satisfaction [START_REF] Bauer | Reply[END_REF]. In addition, it provides a basis of comparison with the published body of literature. Considering these obvious facts, we used the rate of Caesarean Deliveries Avoided (CDA) for the primary analysis followed by the VD24 rate for a secondary analysis. The VD24 rate was calculated including women with CD in the denominator, meaning the entire population. We used DRG rates ranging from 2012 to 2015 according to the date of delivery and expressed them in euros (2020) using French annual consumer price indices and costs, and converted them into US dollar (2020) using the average exchange rate in 2020 both available on the OECD website.

Statistical analyses

Following the analyses in the associated clinical paper, we focused on the perprotocol (PP) population. Economic data for mother or infant were not available for five patients and were imputed by a single imputation method. Descriptive analyses of costs were performed on the incomplete dataset according to the treatment used with mean and bias-corrected and accelerated 95% bootstrapped confidence intervals [START_REF] Barber | Analysis of cost data in randomized trials: an application of the non-parametric bootstrap[END_REF]. A non-parametric Mann-Whitney Wilcoxon test was used to assess cost differences between groups for each variable. Finally, differential costs, effectiveness, and ICERs between misoprostol and dinoprostone were estimated on complete datasets. Bootstrap replications of mean cost and mean effectiveness were used to graphically determine the 95% credible interval of the ICER, with a confidence ellipse [START_REF] Black | The CE plane: a graphic representation of cost-effectiveness[END_REF]. In particular, it allows the variations in outcomes in the ICER calculation to be considered as a probabilistic sensitivity analysis [START_REF] Cohen | Interpreting the results of cost-effectiveness studies[END_REF].

The ICER, bootstrap replications and associated confidence ellipses are drawn in the Cost-Effectiveness Plane (CEP). The CEP is divided into four quadrants. ICERs with a negative value are respectively in the southeast or northwest quadrant and do not require interpretation because the new strategy is less costly and more effective (i.e., a dominant strategy) or costlier and less effective (i.e., dominated strategy) than the reference strategy. ICERs with positive values are in the southwest and northeast quadrant and those in the northeast quadrant are generally compared to the collective Willingness To Pay (WTP) threshold which represents the maximum monetary value that a decision-maker might be willing to pay for a particular unit change in the outcome.

Ethical approval

The French national agency for medicine and health product safety (ANSM) (2011-71 000933-35, A110414-12) and the committee for the protection of people participating in biomedical research (CPP, 1.11.08) approved the trial which is registered at clinicaltrials.gov (NCT 01765881).

Results

Characteristics of the 1,580 women (figure 1), 790 in each arm, included in the PP population are described in table 1. No significant difference was observed between the PP and the intention-to-treat population described in the associated clinical paper and between arms. The most common indications for IOL were post-term pregnancy, premature rupture of membranes, diabetes, and hypertensive disorders.

Economic analyses

The cost comparisons between groups are summarized in table 2. The total mean cost was estimated at €4,400 for the misoprostol group and €4,414 for the dinoprostone group. Mean costs did not significantly differ between groups. We noticed a slight difference between groups related to the use of Oxytocin with a higher cost in the dinoprostone arm (€4,407 vs €4,473, p=0.09). In addition, women in the misoprostol group without a VD24 had a costlier inpatient management (€4,883 vs €4,499, p<0.001).

Cost-effectiveness analysis

Table 3 summarizes both primary and secondary cost-effectiveness analyses. First, the misoprostol group underwent 2.3% more CD and a cost saving equal to €11 ($12) per patient. Therefore, in a cohort of 100 patients, misoprostol allows cost saving of €5 ($5) per patient despite one additional CD. Second, the misoprostol group had 13.5% more VD24 with a cost saving of €18 ($20) per woman. According to the secondary analysis, misoprostol is considered as a dominant strategy because it is less expensive and more effective.

Figures 2 and3 graphically summarize both cost-effectiveness analyses with a 95% credible interval as the basis for the probabilistic sensitivity analysis. According to the primary analysis, we observed a confidence ellipse in the four quadrants which does not lead to a significant conclusion. Nevertheless, the main part of ICER bootstrap replications is located in the northwest and southwest quadrants (i.e., misoprostol a less effective and equally less costly or costlier strategy than dinoprostone), which highlights the trend of dinoprostone being cost-effective compared to misoprostol according to the CD rate. According to the secondary analysis, the 95% confidence ellipse is located in the northeast and southeast (i.e., misoprostol a more effective and equally less costly or costlier strategy than dinoprostone), which emphasizes the costeffectiveness of misoprostol versus dinoprostone. The misoprostol strategy is considered either a cost-effective or a dominant strategy according to the VD24 rate.

Discussion

In both primary and secondary analyses, we could not arrive at a conclusion on the cost-effectiveness of misoprostol compared to dinoprostone. On the one hand, according to the CDA rate, dinoprostone is not cost-effective. Besides, related clinical differences were not significantly assessed. On the other hand, according to the Approximately 25% of women have induced labor in high-resource countries [START_REF] Morris | FIGO's updated recommendations for misoprostol used alone in gynecology and obstetrics[END_REF]9]. Therefore, improvement in IOL management is of major interest, particularly in economic terms given that the effectiveness between current strategies is quite similar [START_REF] Chen | A systematic review and network meta-analysis comparing the use of Foley catheters, misoprostol, and dinoprostone for cervical ripening in the induction of labour[END_REF][START_REF] Alfirevic | Which method is best for the induction of labour? A systematic review, network meta-analysis and cost-effectiveness analysis[END_REF]. However, as a result, the Society for Maternal-Fetal Medicine recently issued a statement that IOL is a reasonable option for low-risk nulliparous women at or after 39 weeks [START_REF] Marrs | Elective induction at 39 weeks of gestation and the implications of a large multicenter randomized controlled trial[END_REF]. The likely increase in the IOL rate makes our trial especially interesting as it provides additional health-economic information. Our primary analysis with the CD rate was based on a non-significant clinical difference between treatment arms. Associated clinical work demonstrated no noninferiority of misoprostol but according to a limited difference in CD rate, both drugs remain considered ref. We believe that this similar efficacy in terms of CD rate underlines the need for additional economic data. Moreover, a significant difference in VD24 rate was estimated between treatment arms and minor differences between the groups for neonatal and maternal morbidity [START_REF] Gaudineau | Induction of Labor at Term With Vaginal Misoprostol or a PGE2 Pessary: a Noninferiority RCT[END_REF].

The DRG and associated rates for each group were quite similar and were mainly affected by additional costs for CD and intensive care which were also similar. This is observable on the confidence ellipses incremental cost variation which was between -€500 and €500. Given that treatment prices are already included in DRG rates, they do not affect the costs analyzed here. Nonetheless, from the hospital perspective, the cost of common drugs is important. FNHI funds hospitals through the DRG rate for stays and the great interest for hospitals is to reduce hospitalization expenses. Firstly, one slow-release dinoprostone pessary costs €83 per patient while a misoprostol capsule costs €0.44, at up to four capsules per patient. Therefore, roughly €82 difference per patient can be applied to the IOLs performed for 22% of the more than 750,000 births per year in France with possible hospital savings of up to €13.5 million annually [START_REF] Blondel | of the National Perinatal Surveys. Trends in perinatal health in metropolitan France from 1995 to 2016 : Results from the French National Perinatal Surveys[END_REF]24]. Secondly, the higher proportion of VD24 in the misoprostol arm (59.4% vs 46.1%) could have a substantial economic impact for hospitals as this clinical outcome is directly related to inpatient cost. In other countries where the incremental price of misoprostol compared to dinoprostone is higher and where the national population is larger, cost saving could be significant. This is particularly true for the US where one slow-release dinoprostone pessary costs $463.88 and one misoprostol capsules costs $0.72 to $5.38, or for low-and middle-income countries with large populations. Nevertheless, a micro-costing methodology is required to consider all cost components in a hospital setting and to confirm these conclusions [START_REF] Frick | Microcosting quantity data collection methods[END_REF].

This work is based on the largest RCT that compares low-dose vaginal misoprostol to the slow-release dinoprostone pessary but has some limitations. The main limit is that we were unable to implement a micro-costing methodology in the RCT because the trial was not designed for this purpose. A hospital perspective would have been a more suitable perspective in this context. Nevertheless, we retrospectively accessed a large part of the mother and infant DRG which allowed us to use an FNHI perspective. Economic data were also missing for 5 women or infants. Imputation was implemented in compensation. Finally, we analyzed the PP population for two reasons. First, there was no difference between intention-to-treat and PP population outcomes in the associated clinical paper. Therefore, we adhered to their primary analysis ref 13, for which the per-protocol analysis was first considered in accordance with a noninferiority trial design (ref 13). Second, the major protocol deviations for excluded women led to additional missing economic data directly associated with these deviations.

From the FNHI perspective, cost management for women who received misoprostol or dinoprostone for IOL is equal. This study contributes additional economic information to associated clinical work to help decision-makers to determine the benefit of one treatment over the other. On the one hand, using CDA rate, we cannot affirm that misoprostol is more cost-effective than dinoprostone. However, using VD24 rate, misoprostol is a dominant strategy. Finally, misoprostol may result in significant cost saving from the hospital perspective, and becomes more attractive than dinoprostone given that the effectiveness is similar and it is easier to use.

  VD24, misoprostol is either a cost-effective or a dominant strategy. The FNHI perspective used in this study does not clearly identify a cost-effective or dominant strategy for one or the other notably because both treatments are supported in the DRG rates. An analysis from the hospital point of view could provide clearer conclusions and highlight the benefit of misoprostol. Economic data related to vaginal misoprostol versus dinoprostone are sparse but seem to converge to a cost-saving use of misoprostol. In 2003, Ramsey et al found cost saving of approximately $500 with significantly less time to delivery or vaginal delivery, and no differences according to the CD rate. The sample size remained limited with 35 -38 women per arm. Two more recent works, respectively in 2016 and 2017 in the USA and Spain, focused on the clinical outcome and/or cost of vaginal misoprostol versus dinoprostone. The first one used single-dose misoprostol 50mcg and showed less time to active labor and delivery and no difference according to CD associated with a $440 hospital cost saving per patient. Nevertheless, only 50 women were included in the misoprostol arm in this retrospective study. The second, with 24 women in the misoprostol and the dinoprostone arms, targeted intrauterine growth restriction fetuses and showed a $315 cost saving per patient for the misoprostol group. Healthcare systems are different around the world, especially because of health care organizations, reimbursement conditions and different unit prices for healthcare resources, which makes the comparison between studies more difficult. However, considering French incremental prices between misoprostol and dinoprostone, our results are consistent with those in the literature.

Figure 1 .

 1 Figure 1. Eligibility Process and Randomization

Figure 2 .Figure 3 .

 23 Figure 2. Incremental cost effectiveness ratio and 95% confidence ellipse according to the CDA rate (primary analysis)

Table 1 . Baseline characteristics of the population Q1

 1 -Q3: First and third quartile; *available for 1,216 women; † available for 1,576 women; ‡ Prolonged pregnancy, taken in isolation, was not a systematic indication for IOL

	Misoprostol	Dinoprostone
	n=790	n= 790

Table 2 . Cost comparison in euros/US dollars (2020) according to adjustment variables, primary and secondary clinical outcomes

 2

			Misoprostol		Dinoprostone
		N (%)	Mean [95% CI]	N (%)	Mean [95% CI]	P
	Global	789

Acknowledgments:

We would like to thank T. Fauchier, M. Frank-Soltysiak, and H. Lefèvre, respectively from Hospital Center Intercommunal Poissy/Saint-Germain-En-Laye, Poissy 78300, University Hospitals of Paris-Sud Bicêtre, Le Kremlin-Bicêtre 94270 and University Hospitals of Strasbourg, Strasbourg 67091, for giving us access to inpatient data from their hospital center.

Author contributions

Mounie Michael participated in designing, planning and conducting the study, analyzing the data and writing the manuscript.

Costa Nadège participated in designing, planning and conducting the study, analyzing the data and writing the manuscript.

Gaudineau Adrien participated in designing, planning and conducting the study, analyzing the data and writing the manuscript.

Molinier Laurent participated in designing, planning and conducting the study, analyzing the data and writing the manuscript.

Vayssière Christophe participated in designing, planning and conducting the study, analyzing the data and writing the manuscript. Derumeaux Hélène participated in designing, planning and conducting the study, analyzing the data and writing the manuscript.

Conflicts of interest:

The authors report no conflict of interest.

Statement of informed consent:

The French national agency for medicine and health products safety (ANSM) (2011-000933-35, A110414-12) and the committee for the protection of people participating in biomedical research (CPP, 1.11.08) approved the trial. We obtained a signed consent and the form is filed with our records.


Shihong Ren
email: shihong.ren@univ-st-etienne.fr

Stéphane Letz
email: letz@grame.fr

Yann Orlarey
email: orlarey@grame.fr

Dominique Fober
email: fober@grame.com

Romain Michon
email: romain.michon@inria.fr

Michel Buffa
email: michel.buffa@univ-cotedazur.fr

Laurent Pottier
email: laurent.pottier@univ-st-etienne.fr

Modernized Toolchains to Create JSPatcher Objects and WebAudioModules from Faust Code

Faust, as an audio domain specific language (DSL) for DSP, has different compilation targets including WebAudio nodes [7, 4]. An AudioWorklet [2] processor wrapping a WebAssembly DSP can be generated statically from native platform compilers as a JavaScript module with wasm files, or dynamically in a browser using a WebAssembly version of the compiler [5]. The WebAssembly compiler has been used in various WebAudio projects through a JavaScript module faust2webaudio, such as the Faust IDE [6] and JSPatcher [8].

In the paper, we present recent work on a new version of the Faust WebAssembly compiler for the WebAssembly target and its JavaScript wrapper module: faustwasm. Using modern JavaScript tools, the module is designed to be crossplatform and runnable under both Node.js and browser environment to generate, compile, and instantiate WebAssembly binary code from Faust code and wrap the binary as an AudioWorkletProcessor. Based on this module, we created faust2wam, a WebAudio plugin generator for the WebAu-dioModule standard with an automatically generated user interface. We also created a tool as an external package for JSPatcher to generate JSPatcher DSP objects in bulk.

INTRODUCTION

Since the support of the WebAssembly features in the AudioWorklet, high performance DSPs can be programmed using low-level code in a WebAudio processor running in a dedicated thread. Despite the complexity of the workflow and the implementation of the JavaScript-side interface, the possibilities of bringing DSP modules from C/C++ code to the Web becomes a hot research topic, as these DSPs initially written for native platforms can be ported to the web using cross-compiler systems like Emscripten [11]. To provide maximum cross-platform compatibility, developers of audio domain specific languages (DSLs), such as Csound [3, 9, 10], Faust or Soul1 contributed tools, compilers, and IDEs to facilitate the compilation of code from these DSLs to web platforms based on WebAssembly and AudioWorklet.

The Faust language has started to support asm.js as a compiler backend since 2015, allowing developers to compile Faust DSPs to JavaScript binary code. Using Emscripten, the Faust compiler itself is also transpiled to a JavaScript module that can dynamically compile and run Faust DSP in the browser. In 2017, a WebAssembly backend has been added in the compiler (libfaust) and additional glue code to transform the DSP to fully functional WebAudio nodes has been developed. faust2webaudio, a modularized version of the Faust WebAssembly compiler and the WebAudio node wrapper written in TypeScript, has been designed in 2019. It is used in multiple Faust projects such as the Faust IDE and JSPatcher.

In this paper, we will present three JavaScript modules related to the Faust language: an updated version of the Faust WebAssembly compiler faustwasm,2 and two DSP generation tools based on this compiler faust2wam3 and @jspatcher/package-dsp. [START_REF] Letz | Faust audio DSP language in the Web[END_REF] faustwasm is an updated version of the previous JavaScript interface of the Faust WebAssembly compiler faust2webaudio. The structure of the module -classes and functions that are usable in the WebAssembly compileris refactored and aligned with the Faust C++ compiler. Thanks to the version 2 of the Emscripten tools, the compiler is now compatible with both Node.js and the web environment, while faustwasm provides a more flexible solution for DSP compilation, packaging, and executing in different contexts and scenarios. The faustwasm module is presented in §2.

faust2wam is a JavaScript tool to generate WebAudio plugins in the WebAudioModules format, with an automatically-generated user interface, supporting parameter automation, and MIDI messages. Additional information on this topic can be found in §3.1. @jspatcher/package-dsp (The DSP package of JSPatcher) contains a large set of modular DSPs allowing programming audio processor graphically in JSPatcher web application. All the DSPs in the package are in static WebAssembly file format generated using a build system with faustwasm (see §3.2).

THE FAUSTWASM MODULE

A complete rewrite of the WebAssembly libfaust glue code has been started at GRAME at the end of 2020 with the following design principles:

1. using a cleaned version of the C++ low-level interface to be compiled by the Emscripten compiler;

2. using TypeScript as the implementation language, to be directly used by TypeScript-based projects, or compiled as a JavaScript library used by JavaScript-based projects;

3. allowing for a pure static model, where the DSP code is separately precompiled as wasm and JSON files by the Faust compiler, then loaded and instantiated using the WebAssembly APis, or dynamically compiled with the libfaust library and then instantiated;

4. allowing the Faust DSP wasm module to be used completely outside of the WebAudio model, for example as a DSP processing piece of code used in a non-real-time context (like processing an audio file) or wrapped as a WebAudio node, 5. allowing for monophonic and polyphonic MIDI controllable nodes;

6. providing some additional capabilities like SVG diagram rendering, for instance.

The new design will help WebAudio and JavaScript developers to easily create audio effects or instruments from Faust source code. The generated DSPs are fully modularized and suitable for various JavaScript environments. The generation is platform-independent and only relies on the browser or Node.js.

faustwasm is a JavaScript module compatible with recent Node.js versions and web browsers. The majority of the codes has been taken from the GRAME branch wasm2 from another JavaScript package @grame/libfaust5 from the Faust repository, [START_REF] Letz | Faust online ide: dynamically compile and publish faust code as webaudio plugins[END_REF] revised to have more compatibility on different environments. Multiple classes are provided to cover complete workflows from the import of the Faust We-bAssembly compiler files generated from Emscripten, to the generation of WebAudio nodes or WebAssembly DSP files.

To cite some important classes, FaustCompiler can use the Faust WebAssembly compiler to generate a Faust DSP binary code from its source code. The binary code can be wrapped with the FaustWebAudioDsp class for audio processing in different contexts. A utility class FaustDspGenerator can be used to quickly obtain processors from the Faust code or from a precompiled WebAssembly DSP. Figure 1 shows the workflow of the compilation with or without FaustDspGenerator. Table 1 shows the description of these classes.

FaustWasm-Instantiator

A helper class instantiating DSP instances from its WebAssembly binary code.

FaustWeb-AudioDsp

A higher-level class wraping one or more FaustDspInstances, providing more detailed descriptor on the user interface, and features for JavaScript callbacks, MIDI messages, and parameters.

FaustOffline-Processor

The class provides a render method for processing "offline" (as fast as possible) an audio buffer through a Faust DSP.

FaustDsp-Generator

The class provides a nearly one-stop solution providing functions to create WebAssembly binary DSP codes from Faust source codes, and generating WebAudio AudioWorkletNodes or ScriptorProcessorNodes using WebAu-dioDsp interface.

FaustSvg-Diagrams

A utility class that can be used to generate Faust DSP block diagrams from source code.

The module distribution contains a version of the original Faust WebAssembly compiler emitted from Emscripten, which includes a JavaScript wrapper file libfaust-wasm.js, a WebAssembly binary file libfaust-wasm.wasm and a complete Faust standard library that is loaded at initialization and accessible in the compiler's in-memory file system libfaust-wasm.data.

Due to a compatibility issue [START_REF] Orlarey | FAUST : an Efficient Functional Approach to DSP Programming[END_REF] with Emscripten and its 1. CommonJS for legacy Node.js packages. With the same format as the libfaust-wasm.js file, it is meant to be used under legacy Node.js environment. When imported in the web environment using the <script> tag, it will automatically assign the module under the faustwasm object in the global scope.

2. ECMAScript (ES) module for both Node.js and the web environment. It includes an adapter to load the libfaust-wasm.js file.

3. ES module bundled with the three files that Emscripten emitted. It is easier to use compared to the previous module, but the file size is larger.

In addition, a command line interface (CLI) is provided for Node.js, the following subsections demonstrate different usages of the module according to Faust's various use cases and scenarios in JavaScript environments.

Static WebAssembly DSP Generation in

Node.js

Before this project, static DSP in WebAssembly format could only be generated using a native distribution of the Faust compiler. Now, it can be done also using faustwasm's Node.js CLI scripts/faust2wasm.js under the project repository, which emits wasm files along with DSP metadata within json files.

The CLI accepts an input source code file path <input.dsp> and an output directory path <output> with two possible options [-poly] and [-standalone]: node scripts/faust2wasm.js <input.dsp> <output> [poly] [-standalone]

• [-poly] option activates the polyphonic mode of the DSP (instrument) and emits additional WebAssembly files that include a voice mixer and a global effect DSP after mixing if it is specified in the DSP source code.

• [-standalone] option puts HTML-related files in the output directory including a UI module faust-ui and a faustwasm distribution to make it independently runnable as a WebAudio node on a web page. The user can open the emitted index.js to test the DSP.

Process Audio Using Faust DSP in Node.js

The scripts/faust2sndfile.js CLI can be used to process or generate audio files in Node.js using Faust DSPs by specifying an input source code file path <input.dsp> and an output wav file path <output.wav>. More options can be added to the command using the syntax: node scripts/faust2sndfile.js <input.dsp> <output.

wav>

[-bs <buffer\_size>] [-bd 16|24|32] [-c < samples>] [-in <input.wav>] [-sr <sample\_rate >]
• [-bs <buffer_size>] option specifies the buffer size in samples (64 by default).

• [-bd 16|24|32] option determines the encoding bit depth of the output wav file, possible values are 16, 24 and 32 (16 by default).

• [-c <samples>] determines the final length of the audio file generated in samples, (5 * sample_rate by default).

• [-in <input.wav>] allows us to specify an input audio file in wav format that can be processed using the DSP.

• [-sr <sample_rate>] option determines the encoding sample rate of the output wav file (44100 by default).

Generate Block Diagram Files in Node.js

The scripts/faust2svg.js CLI can be used to generate Faust block diagram files in svg format. The syntax is as follows:

node scripts/faust2svg.js <input.dsp> <output> where <input.dsp> is the input Faust DSP source code and the <output> is the output directory for the svg files.

Statically or Dynamically Generate Faust DSPs on the Web

With faustwasm, we can generate statically WebAudio nodes from the precompiled WebAssembly DSP binary code, or dynamically generate these nodes starting from compiling the Faust DSP source code.

Once a FaustDspGenerator instance is initialized using the compiler's WebAssembly files, a Faust DSP source code can be compiled into a WebAssembly binary code. Still using the FaustDspGenerator, the binary code -provided either from ArrayBuffers or from precompiled wasm files with its json metadata -can be used to create higher-level DSPs (WebAudio nodes or FaustOfflineProcessors) runnable in the web environment.

USAGES AND EXAMPLES

The faust2wam Module

WebAudioModule (WAM) standard is a web-based audio plugin format first released in 2015. In 2021, a new version of the WAM standard has been redesigned to reflect recent technological developments [1]. A WAM plugin can be fetched from the web using a URI, and initialized using the current WebAudio context. The plugin comes with a standardized API that can create a user interface, get or adjust parameters, schedule events such as parameter automation or MIDI messages, and connect with other WAMs or native WebAudio nodes.

The faustwasm and the faust-ui modules already provide the interface needed for a WAM. Using these modules, we created the faust2wam module to automatically generate a WAM from a Faust code. For any web-based DAW with WAM support, a large amount of audio plugins can be quickly integrated with less effort.

Faust WAM Structure

Figure 2 shows the structure of a WAM plugin, in which the AudioNode of the WAM should be able to interact with the host in both the main and the audio thread. Since the WamNode API is different from the Au-dioWorkletNode API -especially for event handling and parameter automation -it needs to be implemented separately. From the WAM SDK, we imported the Parameter Manager (ParamMgr) and the CompositeNode as a WamNode API proxy to wrap the FaustAudioWorkletNode. The Param-Mgr will be able to automate AudioParams inside the Faus-tAudioWorkletNode, and to send MIDI messages from the WAM API. The node is generated from precompiled static WebAssembly Faust DSP or from Faust source code in the WAM's initialization phase using faustwasm. The WAM also provides a user interface generated using the faust-ui modules.

The system actually produces an extended version of the standalone DSP on the web runtime presented in the Subsection 2.1. During the initialization phase, the WAM will execute the following steps to construct an AudioNode that conforms the required WAM API (Figure 3):

1. json and wasm files containing the DSP's metadata and binary codes will be fetched and compiled to We-bAssembly Modules.

2. A FaustAudioWorkletNode (FaustNode) will be created using the FaustDspGenerator.

3. The node's parameters will be used to initialize a ParamMgr that proxies the WamNode API.

4. The FaustCompositeNode that wraps the ParamMgr and the FaustNode will be created as the "main" node of the WAM to connect with other AudioNodes.

In addition, a function that can create a user interface from the DSP's metadata using faust-ui in a WebComponent is attached to the WAM. The generated files inside the output directory will be selfcontained, including all the modules required by the WAM.

Generate on the Web

Thanks to the Faust WebAssembly compiler in the faustwasm module, it is possible to generate a Faust WAM directly in the web environment.

A compile function is provided in the faust2wam package to compile Faust code to the WebAssembly binary code with the DSP metadata. Then, users can call the generateWam function to generate the FaustAudioWorkletNode and wrap it into a WAM, which will be the same as from static files.

Figure 4 shows a WAM generated by faust2wam module.

The DSP Package of JSPatcher

JSPatcher is a visual programming language (VPL) on the web written in TypeScript in the style of Max or PureData allowing users to create interactive online applications by building a graph -connecting ports (inlets and outlets) of the "box objects" with virtual patch chords.

A box object can be functional, accepting data as function inputs from its inlets connected from other box objects. Then, after applying the function to the input, it will output data to other box objects from its connected outlets.

Meanwhile, if supported, a box object can be used as a WebAudio DSP node, while its ports represent audio connections as in a WebAudio graph. Cables will be colored in this case.

Since an SDK for creating third-party box objects is available publicly, based on the faustwasm module, a set of JS-Patcher DSP objects for basic signal calculations is created as a package that is added into JSPatcher, to extend its possibilities for real-time signal processing.

In the design, this statically compiled Faust DSP box object can have several options during runtime, including setting initial values of most of the inputs and setting interpolation time when these inputs are changed by messages (which is 0.01 second by default).

A Faust library maxmsp.lib 8 has implemented in the 8 https://github.com/grame-cncm/faustlibraries/blob/ Faust language a part of the DSPs in Max. Our work reused some functions from the library and quickly prepared for each DSP box object a dedicated Faust source code file. For example, to prepare the source code of the low-pass filter (LPF), we only need to write the following:

declare argsOffset "1"; declare description "Low Pass Filter"; declare inputsDescription "['','f0','gain','Q']"; import("maxmsp.lib"); // Import the Library process = LPF; // Set as the main process

Here, the first three lines allow providing additional metadata with the compiled DSP, to be injected into the JS-Patcher box object. argsOffset is declared to be 1, which means that the arguments of the resulting box object will be applied to the inputs with an offset of 1 (i.e., the first argument to the second input). The description and the inputsDescription will be showed with the box object as its metadata. Due to the limitations of the compiler, in inputsDescription, backquotes are used as delimiters for strings and will be replaced as quotes in order to be parsed as a JSON array.

To support the initial input value when the box object's inlet is not connected, we may also need to declare the value through the metadata. The code below is another example showing how we declare initial input values in the Faust source code. declare defaultInputs "[0, 0.5]"; declare description "Sawtooth waveform oscillator between 0 and 1 with phase control"; declare inputsDescription "['freq', 'phase']"; import("stdfaust.lib"); process = os.lf_sawpos_phase;

The defaultInputs indicates (in order) the default input values as a JSON array of numbers.

Once the source files are prepared, we use the faustwasm CLI to compile all the files to its WebAssembly binary and JSON metadata files.

Then, a prototype JSPatcher box object is created as a class that extends (DefaultObject). It includes the FaustD-spGenerator for compiling the WebAssembly binary to the FaustAudioWorkletNode, taking into account the metadata declared in the source code. In fact, to implement the default argument values, for each Faust DSP input (which is actually different FaustAudioWorkletNode channels of its first input), a ConstantSourceNode is initialized with the declared value as its offset AudioParam value and connected to a ChannelMergerNode which connected to the FaustAu-dioWorkletNode. To allow us to separate connections from each DSP output, a ChannelSplitterNode is connected to the first output of the Faust node. (Figure 5)

With this setup, the box object's inlets can be connected with audio connections for a-rate parameter changes on the offset AudioParam, which is eventually treated as signal inputs. Without audio connections, they can also handle data messages to set discretely input values with a smooth factor, which can be set through the box object's smoothInput property.

Figure 6 shows that when the user added a Faust DSP box object in JSPatcher, the detailed descriptions declared master/maxmsp.lib in the metadata will show up. In this case, a simple phasor waveform generator is created using the phasor~box object. It has two inputs, freq and phase, which can be initialized with arguments. Figure 7 shows the output signal or the phasor~box object with the frequency set to 110Hz. We connect the output to another Faust DSP box object subtracting the signal by 0.5, then to an oscilloscope to visualize the signal.

DISCUSSION

The faustwasm module uses several recently implemented Web APIs, including ES module, WebAssembly, Au-dioWorklet, etc. Its browser compatibility need to be investigated. According to caniuse.com, WebAssembly and ES modules with dynamic import support are available on popular browsers (Chromium, Firefox, and Safari) since May 2020. AudioWorklet API is supported on Chromium since 2018, on Firefox 2020. Safari started supporting since 2021, but not allowing passing constructor options to the processor. In 2022, Safari's Technology Preview has full support for AudioWorklet.

After releasing the first version of faustwasm, we have a feature request for sample-accurate handling for MIDI messages and parameter changes. A solution is proposed by the community and will be addressed soon. We are also expecting to see more use cases from the Faust community. In theory, multi-rate audio processing or non-audio data stream processing (i.e. frequency domain data calculation) will be possible using this module on the web. We will keep the module up to date to keep the Faust language usable in new audio projects and new web technologies. Cross-platform compatibility is one of the main design features of the Faust language. It is also one of the capabilities provided by the web standards and browsers. Different modern Web APIs and web-related programming workflows, including new languages, building systems, and rendering frameworks require the Faust compiler and DSPs to be highly flexible and modularized for easier integration into third-party projects.

CONCLUSION

Both faust2wam and the DSP package for JSPatcher are proofs of concept of using faustwasm as a NPM (Node Package Manager) module for WebAudio related projects. We are going to merge the module into Faust official repository and replace old web compilers in our online tools such as the Faust Editor, the Faust Playground and the Faust IDE. With the next iteration of these tools, the Faust compilation service on a remote server is no longer needed for JavaScript targets, WAMs with a UI can be efficiently generated in a browser.

Web-based audio application like JSPatcher often need a set of DSPs implemented as AudioWorkletNodes. faustwasm could help developers in this case concentrate on the DSP algorithm and realize the JavaScript programs for them. With less coding efforts, we successfully created around 50 DSPs for JSPatcher and will add more in the future.

ADDITIONAL AUTHORS

Additional author: Yang Yu (Shanghai Conservatory of Music, SKLMA, China, email: yuyang@shcmusic.edu.cn).

Figure 1 :

 1 Figure 1: The complete workflow to generate Faust WebAudio nodes from source code using faustwasm.

Figure 2 :

 2 Figure 2: The WebAudioModule API structure.

Figure 3 : 2

 32 Figure 3: The FaustCompositeNode structure.

Figure 4 :

 4 Figure 4: A Faust polyphonic WAM generated by faust2wam and loaded in JSPatcher, connected with a virtual keyboard and an oscilloscope.

Figure 5 :Figure 6 :

 56 Figure 5: The internal WebAudio graph in a Faust DSP box object.Object Inlets

Figure 7 :

 7 Figure 7: The signal that the phasor box object generated.

Table 1 : Classes and their description in faustwasm

 1

	Class	Description
	FaustModule	The class exported from the Em-
		scripten compiler, containing raw
		memory states, function callers and
		an in-memory file system aligned with
		C/C++ interface.
	LibFaust	A simple JavaScript wrapper class
		around FaustModule containing only
		necessary methods.
	FaustCompiler An important class handling the full
		lifecycle of a Faust DSP binary code
		generation process from its source
		code, including caching, error han-
		dling, cleanups, and providing poly-
		phonic instrument mixers.
	FaustDsp-	A class interfacing single Faust DSP
	Instance	instance processing audio buffers, pro-
		viding information, and handling pa-
		rameter changes.

https://soul.dev/

https://github.com/Fr0stbyteR/faustwasm

https://github.com/Fr0stbyteR/faust2wam

https://github.com/jspatcher/package-dsp

https://www.npmjs.com/package/@grame/libfaust

https://github.com/grame-cncm/faust

https://github.com/emscripten-core/emscripten/issues/


Quentin Beauchet

Pierre Kouyoumdjian

Michael Marynowicz

Yann Forner

Michel Buffa

Making a guitar rack plugin -WebAudio Modules 2.0

WebAudio Modules 2.0 (aka WAM) is a standard for developing interoperable host and plugins. that can be written using different development approaches (JavaScript, build systems, TypeScript, FAUST, Csound, front-end frameworks, etc.). In addition, the WAM standard includes the notion of group of plugins, in order for example to send MIDI events to a group of plugins or to unify their parameters in a single set. The demo we propose is about a plugin that acts as a host, that exploits the WAM group feature of the WAM SDK and manages a set of plugins. This plugin regroups guitar pedal effects and tube amp simulators plugins to propose a large set of sound presets organized in banks. It can be loaded by any WAM compatible 1 https://github.com/webaudiomodules and https://www.npmjs.com/settings/webaudiomodules/packages host, be it a single HTML page with a few lines of JavaScript or a complete DAW. Both cases will be demonstrated.

Introduction

In 2015 Jari Kleimola and Oliver Larkin created Web Audio Modules (WAM) [START_REF] Kleimola | Web audio modules. 12th Sound and Music Computing Conference (SMC15)[END_REF], a standard for creating reusable and interoperable plugins implemented as WebComponents, the core of which was written in C/C++. This initiative was aimed primarily at developers of native plugins (i.e. VST plugins). Since then, this standard has evolved in a new "Web Audio Modules 2.0" (WAM2) version [START_REF] Buffa | Web Audio Modules 2.0, an open Web Audio plugin standard[END_REF], taking into account feedback from developers of the first version and the evolution of web Ssandards (with WebAssembly, WebComponents, WebMidi etc.). The WAM distribution is open source and distributed as four GitHub repositories and as npm modules (MIT License) 1 . One of these repository, the wamexample github repository, contains different plugins and hosts, that cover different programming languages and approaches. One of these examples is a proof of concept of a guitar pedalboard plugin written using the React front-end framework. This example is incomplete and the use of React adds an extra layer of complexity. WAM2 creators asked us to develop a simpler (pure JavaScript) example that can show some remarkable features of the standard, in particular the use of WAM groups and in particular, how to achieve parameter automation of a group of plugins that can be added/removed on the fly. Furthermore, as a large amount of our plugins are AudioWorklet / WebAssembly based, showing how the WAM standard could perform while automating a large amount of parameters without leaving the audio thread (with a host also written as an AudioWorklet) was something we wanted to experiment with.

Related works

Several people tried to develop guitar effects and amplifier simulations with WebAudio. However, the vast majority of these projects does not use reusable, interoperable plugins, or used proprietary formats just usable with their own host. Among the oldest open source projects are pedalboard.js 2 and the Guitar Pedal Board [START_REF] Buffa | Guitar pedal board using WebAudio[END_REF]. JS-Rocks 3 proposed in 2018 a set of guitar pedal effects and amplifiers (using Angular for the GUI). Other projects have been recently presented at different JavaScript developer conferences 4 , but most of them use "rather" simple effects coded using high level WebAudio nodes, and do support more complex approaches involving Web Assembly, Domain Specific Languages (DSL) or ports of VST/C++ cross compiled code, like our version does, that open the doors to sample accuracy audio processing. We are also using a large set of WASM/AW based plugins in our pedalboard. The most advanced examples you can find are in commercial online DAWS (bandlab.com, soundtrap.com or ampedstudio.com -this last example uses WAMs that some authors of this paper have developed). In 2018 a pedalboard project used interoperable plugins [START_REF] Buffa | Guitarists will be happy: guitar tube amp simulators and FX pedals in a virtual pedal board, and more![END_REF] and has been presented at the WebAudio Conference in Berlin. It was built with an older version of the WAM standard. The demo we proposes, while having less GUI features, proposes more advanced capabilities. 3 https://github.com/vitaliy-bobrov/js-rocks 4 For example https://github.com/trys/pedalboard

The WAM pedalboard plugin

The WAM pedalboard plugin can be tried online 5 with an embedded audio player or using a real guitar and a sound card. It acts as a host and can handle a large set of plugins. According to the WAM specification, each WAM plugin is identified by a URI. From this URI it is possible to fetch metadata about the plugin (name, version, category, author, description, but also an image thumbnail). It is also possible to fetch the plugin code and to instantiate it using a single JavaScript dynamic import. Each plugin is a WebComponent. The WAM pedalboard uses a JSON configuration file that contains an array of URIs, each corresponding to the different WAM providers. Plugin providers can have an absolute URI (remote third party server ) or a relative URI (in this case the plugins are located under the base URI of the pedalboard itself). Along the pedalboard we provide a local set of plugins, but we also set up a remote server with another set of plugins (source code also available in the wam-example GitHub repository6 ). When instantiated, the pedalboard queries all these WAM providers and builds an internal description of the available plugins. Thumbnails of these plugins are displayed on the top row, and can be sorted by categories using a drop down menu.

By clicking on thumbnails plugins are downloaded and instantiated and a plugin chain can be assembled (Fig 1 .). Plugins in the chain can be dragged and dropped to change the order, or deleted. All controls are usable (knobs, switches etc.). When plugins are added or removed, the internal set of parameters of the pedalboard are updated and events are fired, that can be caught by the host (for updating the parameter automation menu, for example). Each plugin can be controlled using any MIDI control device (knobs, sliders, switches are all made with the webaudiocontrols library7 that proposes a set of web components with midi learn features).

The pedalboard plugin also comes with a bank/preset manager. In the WAM specification, each plugin has a state (i.e the current value of its exposed parameters, that often is also the position of each know/slider/switch in its GUI). The state of the pedalboard is a composite set of all its internal plugin states, plus a description of its presets and banks. The order of each plugin chain in each preset is also part of the state of the pedalboard.

Like this, a DAW that would use one or more pedalboard plugin(s), will be able to save/restore its/their full state(s) with a song project, for example. At the time of writing we have about twenty audio effect plugins and three tube guitar amplifier simulators, but we are currently porting a much larger set of plugins we developed with a previous version of the plugin standard [START_REF] Ren | FAUST online IDE: dynamically compile and publish FAUST code as WebAudio Plugins[END_REF]. For the demo we plan to have more than seventy plugins available. Our proposed demonstration is a good test bench to assess the current limitations of Web Audio in terms of latency (driver, audio buffer size, sample rate frequency, etc.), audio effect sound quality, etc.

Settings for the demo

Our pedalboard can be played real-time with a real guitar. As of today, we recommend for the best experience to use MacOS and a low latency sound card. By using a real guitar, we propose to show that WebAudio plugins for guitarists are a reality and could be included in full-scale DAWs with a quality comparable to what we find in the native application world.

  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 Figure 1: A composite plugin that acts as a host

Figure 2 :

 2 Figure 2: Typical setup

https://wam-bank.herokuapp.com/

https://github.com/webaudiomodules/wam-examples

https://github.com/g200kg/webaudio-controls

5.