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

HAL
open science

# Pharo Sound Design: Adding Auditory Feedback to a Live Programming Environment

Domenico Cipriani, Gabriel Darbord

► To cite this version:

Domenico Cipriani, Gabriel Darbord. Pharo Sound Design: Adding Auditory Feedback to a Live Programming Environment. Journées d'Informatique Musicale, GRAME; Inria, Jun 2025, Lyon, France. hal-05102350v2

HAL Id: hal-05102350

https://hal.science/hal-05102350v2

Submitted on 17 Jul 2025

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

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
# PHARO SOUND DESIGN: ADDING AUDITORY FEEDBACK TO A LIVE PROGRAMMING ENVIRONMENT

Domenico Ciprianiª, Gabriel Darbordᵇ

ªPharo Association

ᵇUniv. Lille, Inria, CNRS, Centrale Lille,
UMR 9189 CRISTAL, F-59000 Lille, France

## RÉSUMÉ

Nous présentons un prototype d'intégration de signaux auditifs dans l'environnement de développement intégré (IDE) Pharo afin de favoriser la prise de conscience du flux de travail et d'explorer l'interaction multimodale. Pour ce faire, nous utilisons les capacités de synthèse de la bibliothèque et de l'API Phausto, qui gère le traitement des signaux numériques via un compilateur Faust intégré. Cela nous permet d'associer des signaux à des événements visibles par l'utilisateur sans modifier le code source d'origine. Nous décrivons un ensemble de signaux auditifs déclenchés par des événements et la logique qui sous-tend leur conception. Nous décrivons ensuite les composants nécessaires à l'instrumentation et à la lecture cohérente de ces signaux. Cette approche fournit une base pratique pour poursuivre l'expérimentation avec le son dans des environnements de programmation en direct.

## ABSTRACT

We present a prototype for integrating auditory cues into the Pharo Integrated Development Environment (IDE) to support workflow awareness and explore multimodal interaction. To achieve this, we use the synthesis capabilities of the Phausto library and API, which handles digital signal processing through an embedded Faust compiler. This allows us to attach cues to user-facing events without modifying the original source code. We describe a set of event-driven auditory cues and the rationale behind their design. We then describe the components required for instrumentation and consistent cue playback. This approach provides a practical foundation for further experimentation with sound in live programming environments.

## 1. INTRODUCTION

According to the ISO standards [8], accessibility is the extent to which systems, services, environments, and services can be effectively used by individuals with diverse needs and abilities to achieve specific goals in a given context. In recent years, auditory representations have received growing attention across a wide range of research initiatives, extending their application to a broader variety of domains and contexts [6]. In this work, we explore our solutions for augmenting the accessibility and workflow

of the Pharo Integrated Development Environment (IDE) by integrating auditory cues. In this initial stage, we will employ sonification techniques [11], a subset of auditory display methods that use non-speech audio to convey information.

As accessibility in software becomes increasingly important [2], auditory feedback is essential in improving the user experience, particularly for people with visual impairment. To achieve this goal, we rely on:

* The synthesis capabilities of the Phausto [5] library and API, which integrate digital signal processing capabilities through an embedded Faust compiler (see Section 2.2 and Section 2.3)

* Code instrumentation(see Section 4) that allows us to generate auditory notifications without modifying the original source code of the tools and methods identified for intervention.

Achieving full accessibility in Pharo is a long-term effort that is still in its early stages. An essential final step will be the integration of a text-to-speech (TTS) add-on, which appears feasible due to the *Formant Synthesis* functionalities already implemented in Faust's standard abilites and the ease to build a *Text-To-Phoneme converter* in Pharo using PetitParser2.<fnref n="1" />

## 2. TECHNOLOGIES USED

### 2.1. Pharo and its IDE

Pharo is an open-source, dynamically typed programming language rooted in Smalltalk, which makes live coding and Test-Driven Development easy and intuitive [7]. It is image-based: the entire development environment, including source code, runtime state, and tooling, is stored in a single snapshot file that can be saved, restored, and shared across systems. Its platform-independent, feature-rich IDE provides robust tools for developing and executing code interactively, along with efficient class management through package-based organization, advanced debuggers, and object inspectors. The syntax of Pharo is

<footnote n="1">¹ PetitParser2 is a framework for building parsers [13].</footnote>
minimalist and similar to a language pidgin.<fnref n="2" /> Pharo fosters an inclusive community that welcomes coders from all over the world, regardless of their level of experience and background, and promotes a culture where improvements and additions to its ecosystem are encouraged.

## 2.2. The Phausto library and API

Phausto [4] is a multi-platform library and API that enables sound generation and DSP<fnref n="3" /> programming in Pharo. The audio is generated via FFI<fnref n="4" /> calls to a *dynamic engine*<fnref n="5" /> that computes the audio signal, relying on the embedded Faust compiler (see Section 2.3) that enables sound synthesis and processing. This dynamic engine is also responsible for populating the buffer of the underlying audio driver with the samples computed by the compiled Faust DSP, which are ultimately sent to the audio output for playback (see Section 2.3). Phausto offers a simple and clear API to program DSP circuits and to use all the functions defined in the extensive Faust libraries functions, which include state-of-the-art oscillators, filters, physical models, and effects. The Faust functions have been implemented in Phausto as subclasses of the Unit Generator class, which expose all original arguments as instance variables [5] whose default values are set at their initialization. These subclasses are inspired by the ChucK programming language [17]. Here is an example of code using Phausto:

```
"Create a minimal synth with a Square Oscillator and
an Attack/Release envelope."
```

```
"Set the label of the envelope trigger parameter to
#gate"
```

```
synth := SquareOsc new => (AREnv new trigger: #gate).
```

```
"Create a stereo DSP from the synth"
```

```
dsp := synth stereo asDSP.
```

```
"Initialize and start the DSP"
```

```
dsp init; start.
```

```
"Trigger the synth envelope"
```

```
dsp trig: #gate.
```

```
"Stop and destroy the DSP"
```

```
dsp stop; destroy.
```

## 2.3. The Faust compiler

Faust (Functional Audio Stream) is a functional, domain specific language designed for programming Digital Signal Processing (DSP) with a high level of performance [12] inside libraries, audio plug-ins or standalone

applications. A signal processor represented by a Faust program is a mathematical function that converts an input signal into an output signal. To connect this DSP module to the external world, architecture files [1], such as the *dynamic engine* used in Phausto, specify the details about audio drivers and controllers (such as GUI and MIDI). The dynamic engine compiled for Phausto specifies CoreAudio as the audio driver on macOS, PortAudio on Linux and Windows, and employs the interpreter backend<fnref n="6" /> for the Faust compiler. The Faust compiler translates Faust programs into equivalent C++ code, optimized for maximum efficiency. The generated code can be easily embedded into various applications. This compiler makes audio generation from Pharo possible, delivering high-quality results without the need for any external programs.

# 3. DESIGNING AUDITORY CUES FOR IDE EVENTS

To explore how auditory cues can enhance user interaction in a live programming environment, we selected five events in the Pharo IDE, each corresponding to a distinct type of system feedback. We chose these events because they are common in day-to-day development and are already associated with visual indicators. Our goal is to supplement these existing visual cues with short, informative auditory signals that convey the nature and severity of each event without disrupting the workflow.

Each auditory cue, or earcon [15], is composed of one or more brief tones, played using the same synthesizer instrument to ensure a consistent sound palette across all events. The cues differ in pitch content and melodic contour to reflect the meaning of each event, while remaining recognizable as part of a coherent set.

For each event, we first describe how it is triggered and presented to the user in the Pharo environment, then explain the rationale behind the corresponding earcon's design.

### 3.1. Test Success Event

This event occurs when the developer executes a test or test suite and it completes successfully. In Pharo, running tests is typically done from the user interface: the code browser displays a button next to each test class and test method. Clicking one of these buttons runs the corresponding suite or test, and the button changes color to indicate the result, as shown in Figure 1. A gray button indicates that the test has not run (e.g., `testSkip`), a green button means the test passed (e.g., `testPassing`), a yellow button means the test failed due to an assertion (e.g., `testFailing`), and a red button means an error occurred (e.g., `testError`). In addition to these local

<footnote n="2">² A pidgin is a grammatically simplified language that emerges when two or more groups need to communicate but don't share a common language. Over time, the pidgin may evolve into a creole, a fully developed, stable natural language [16].</footnote>

<footnote n="3">³ Digital Signal Processing (DSP) is a branch of engineering and applied mathematics that deals with the processing and analysis of digital signals.</footnote>

<footnote n="4">⁴ A Foreign Function Interface (FFI) is a mechanism that enables software in one language to access functions and data structures written in another language, usually through shared or dynamic libraries. These libraries are typically written in C or another language with a compatible Application Binary Interface (ABI) [14].</footnote>

<footnote n="5">⁵ The dynamic engine is a Faust DSP architecture developed by Stéphane Letz: https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/faust-dynamic-engine.h</footnote>

<footnote n="6">⁶ To meet the design goals of Phausto, the interpreter backend was chosen due to its lack of external dependencies. While we acknowledge that the interpreter backend is slower compared to the LLVM compiler, we do not expect this will significantly affect Phausto's target audience [4].</footnote>
indicators, a system-wide notification also appears to summarize the test results, as shown in Figure 2. When all executed tests have passed, the notification will have a green background. This last event is the target for one of the earcons we introduce.

<figure><img src="image_2.png" /><figcaption>**Figure 1.** Buttons next to test methods in the Pharo code browser.</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>**Figure 2.** Notification of test results in the Pharo environment.</figcaption></figure>

A successful test run is a frequent and positive event in iterative software development. To reinforce the positive outcome, we chose an A major triad played as an ascending arpeggio: A4 (440 Hz), C#5 (554 Hz), and E5 (659 Hz). The upward melodic contour and use of major intervals provide a subtle sense of resolution, progression, and encouragement without becoming exuberant. This cue reaffirms correct behavior and indicates a smooth progression in the development process.

## 3.2. Test Failure Event

This event occurs when the developer executes a test suite and one or more tests fail. A test that fails an assertion turns the aforementioned button orange, while an uncaught error turns it red. If a single test is executed and fails for either reason, the debugger opens on the corresponding exception: this event is handled by a separate earcon, discussed below. The present event focuses instead on the failure of a test suite, where the failure does not invoke the debugger. In such cases, the existing visual cue is a system-wide notification that summarizes the results with a red background, as shown in Figure 2, indicating that at least one test failed.

To signal this failure, we designed an earcon that conveys concern without escalating to a critical tone. We use a descending minor third: D5 (587 Hz) dropping to B4 (494 Hz). The descending melodic contour communicates that something has gone wrong, and the minor interval introduces a subtle dissonance. By emphasizing a subtle drop, the cue remains distinct and informative, but avoids sounding overly alarming. Its frequency range overlaps with the test-passed earcon to maintain a consistent sound palette.

## 3.3. Notification Event

This event occurs when the system provides non-intrusive feedback for informational purposes, such as after saving the image or creating a file at the user's request (for example, when exporting code to a file). In Pharo, notifications are implemented as small text boxes, known as toasts or growls, that appear briefly in the corner of the interface and fade away after a few seconds. They are purely informative and do not require any user interaction. An example of a notification is shown in Figure 2. As explained above, running tests also triggers a notification, so in this scenario we mute the notification to give priority to the test status earcon to avoid overlapping auditory cues. Because of their transient and visually subtle nature, they can easily go unnoticed, especially if the user is focused elsewhere in the interface.

To reinforce the presence of such notifications, we designed a short, neutral earcon consisting of a single note: E5 (660 Hz). As the perfect fifth above A4, E5 has a stable and pleasant character and cuts through ambient noise without being intrusive or shrill. The brevity of the cue mirrors the ephemeral nature of the visual toast and signals that something occurred, but no immediate action is required. Functionally, this earcon serves as the auditory equivalent of a visual badge or icon, drawing the user's attention to new information.

## 3.4. Recoverable Exception Event

This event occurs when the debugger opens due to a resumable exception. In Pharo's live programming environment, the debugger is a central tool for handling unexpected conditions during execution. Exceptions can be divided into two categories: resumable and non-resumable. Resumable exceptions allow the developer to regain control of execution, inspect the context, and then choose to resume program execution. They are used to signal warnings, situations where something unusual has happened, but where the system can continue to run after the user acknowledges. They are also used for interactive debugging purposes, such as breakpoints, which intentionally pause execution to allow the user to explore the program state.

To signal that a debugger has opened and that user action is required, we designed an earcon based on a dissonant interval: a tritone from F4 (349 Hz) to B4 (494 Hz). The tritone spans six semitones and is historically associated with tension and ambiguity. Its unresolved quality communicates that something has happened and warrants attention, but without suggesting fatal failure. This cue is intended to be noticeable and serious, while still conveying that the situation is recoverable. It complements the visual appearance of the debugger and reinforces the mental model of a recoverable interruption in the program flow.
## 3.5. Critical Error Event

This event occurs when the debugger opens due to a non-resumable exception. As with resumable exceptions, the debugger allows the developer to inspect the execution context and understand what went wrong. However, non-resumable exceptions reflect a critical failure: execution cannot be resumed because the program encountered an unrecoverable error and had to stop.

To reflect this increase in severity, we designed an ear-con that builds on the warning cue. It begins with the same dissonant tritone interval from F4 (349 Hz) to B4 (494 Hz), establishing tension and uncertainty. The sequence then descends further to D4 (294 Hz), forming a minor sixth drop from the previous note. This final drop introduces a deeper and more somber tone, adding a sense of failure and instability. The lack of tonal resolution, combined with the extended descent, communicates that the situation is beyond recovery. This cue thus conveys a sense of urgency and finality, consistent with the presence of the debugger in a state where execution cannot continue.

## 3.6. Design Rationale

In designing these earcons, we selected pitch intervals and melodic contours that reflect the character and severity of each event, while maintaining a coherent auditory language across the system. Each cue establishes a distinct identity through its interval structure and melodic direction, yet all share a consistent timbral quality by using the same sound synthesis instrument. This uniform sound palette contributes to recognizability and learnability, allowing developers to associate specific cues with particular events over time. By reinforcing key interface events with concise auditory feedback, this approach aims to enhance situational awareness and reduces reliance on visual cues.

# 4. USING INSTRUMENTATION TO AUGMENT PHARO

To integrate auditory cues into the Pharo IDE without modifying its original source code, we rely on instrumentation. Instrumentation allows us to dynamically inject behavior into existing methods at runtime, which is particularly well suited to Pharo's live programming environment. This approach enables us to attach sound playback logic to existing system events while preserving the editability and integrity of the source code. The following describe how the events are instrumented, and how we use Phausto to play the audio cues.

## 4.1. Injecting Behavior with Method Proxies

To add auditory cues to the Pharo environment, we need a way to execute additional code in response to specific events—such as running tests, opening the debugger, or showing a notification. Since Pharo is a live programming

environment, where code can be edited and executed interactively, directly modifying the source code of existing methods would be fragile and undesirable. Not only would it risk introducing errors, but it would also tightly couple unrelated concerns, making further changes to the system harder to reason about and maintain.

Instead, we rely on instrumentation, a technique that allows behavior to be injected into running systems without altering their source code. Instrumentation is particularly well suited to dynamic environments like Pharo, where methods can be modified or redefined at runtime. It enables us to attach code that runs before or after a method is executed, effectively allowing us to intercept control flow and react to system events.

In our prototype, we implement instrumentation using the *MethodProxies* library [9], a safe and low-overhead framework for message-passing control in Pharo. MethodProxies provides a mechanism to wrap existing methods with pre- and post-execution hooks, while avoiding common pitfalls such as infinite recursion or reflective instability. Unlike source rewriting or method substitution, this approach offers a reliable and efficient foundation for injecting behavior into a live system.

Our instrumentation architecture is structured into two layers. At the lower level, the *execution layer* uses MethodProxies to manage the installation and removal of method hooks. This layer is responsible for redirecting control flow from the original method to user-defined logic, without modifying the method body itself.

On top of this, the *event logic layer* defines the behavior to execute in response to instrumentation hooks. This layer maps Pharo IDE events, such as a test passing, a notification appearing, or the debugger opening, to specific auditory cues. To do this, we identify and instrument the methods responsible for triggering the corresponding visual feedback in the user interface. For example, the ear-con for the *test success* event is triggered by instrumenting the method in the code browser API that handles test execution and result display when the user clicks the associated button. This is more accurate and context-sensitive than instrumenting the test runner itself, which may be used in non-interactive scenarios, such as programmatic test execution or scripts.

Some methods correspond to multiple events depending on runtime context. To disambiguate such cases, the instrumentation logic can inspect the receiver, arguments, or the context available at the time of the method call. For instance, the same method is invoked when the debugger opens, regardless of whether the underlying exception is resumable or not. By querrying the exception object, we determine whether to play the *warning* or *error* earcon.

To refine the user experience, each event handler tracks a local *muted* state, which can be toggled at runtime to suppress cues when overlapping events occur. As noted in Section 3, the *test success* event also triggers a notification. In such cases, the notification is muted to avoid redundant feedback and prevent auditory clutter.

This layered and context-aware strategy enables us
to integrate auditory feedback into the Pharo IDE in a
way that complements its visual interface without over-
whelming it. By targeting user-facing methods, condition-
ing execution based on context, and managing cue over-
lap, we ensure that earcons remain informative and well-
integrated within the live programming workflow.

## 4.2. Orchestrating Cue Playback

The actual sound generation is handled by the Phausto li-
brary, which delegates audio computation to a *dynamic*
*engine* implemented in Faust and exposed to Pharo via
FFI. However, because the DSP is allocated outside the
Pharo image in external memory, it is not preserved across
sessions. While Pharo objects, including instrumentation
hooks, persist between image saves, the state of the au-
dio engine must be reinitialized after each restart. To ad-
dress this mismatch, we designed a dedicated architecture
to manage the lifecycle of the DSP and automatically re-
store it when the image is started.

At the core of this architecture is an *Instrument* class that serves two purposes. First, it defines the Phausto synthesizer used to generate all audio cues. As described earlier, we use a single instrument configuration for all earcons in order to maintain a coherent sound palette. This synthesizer is instantiated at startup by a restoration mechanism that automatically detects and reinitializes instrument classes.

Second, the *Instrument* class is responsible for cue playback. While Phausto provides primitives for triggering individual notes, it does not support higher-level structures like earcons. To produce each cue, we orchestrate multiple note triggers with specific pitches and delays defined in Pharo code. In addition, this code must be executed asynchronously relative to the triggering event to avoid blocking the original flow of the program while the cue is being played.

# 5. PROJECT VALIDATION AND USER TESTING

The earcons described in Section 3 have been successfully implemented but not yet empirically validated. A formal evaluation would be necessary to assess whether the intended perceptual and functional qualities of each signification <fnref n="7" /> are accurately conveyed to users. Validating our approach requires controlled user studies to measure reaction time, recognition accuracy, and subjective responses to each sonification in context. Methodologies from existing work on sonification and earcon usability (e.g., [10, 3]) offer a starting point for designing such experiments. These experiments can be conducted at the European Smalltalk User Group (ESUG) conference, involving participants who are familiar with Smalltalk integrated development environments. To support these experiments, our prototype should be extended with at least two additional sets of earcons, as proposed by Kramer [10], to allow a comparative analysis of their effectiveness. The extensive range of oscillators and physical models available in the Faust standard library is fully accessible through the Phausto library, facilitating the efficient creation of varied auditory cues. These evaluations would help confirm or refine the design justifications presented here.

# 6. CONCLUSION

In this paper, we presented a prototype for integrating auditory feedback into the Pharo IDE using event-driven earcons. By leveraging instrumentation, we attach sound cues to user-facing events without modifying the original source code. This approach is well suited to Pharo's live programming environment, as it maintains compatibility with runtime code modifications and preserves separation of concerns.

The system is structured around two concerns: instrumentation, with the help of the *MethodProxies* library, and cue playback, using Phausto to play a synthesizer. Each earcon is designed to complement an existing visual cue, providing a consistent and non-intrusive audio layer for events such as test execution, debugger activation, and notifications. A demonstration of the initial results of the prototype, including both visual and auditory feedback, is available at https://youtu.be/ZeikLaowgqQ.

Our current design treats earcons as predefined, static sequences. While grounded in music theory, we have not yet conducted empirical studies to validate the perceptual or usability effects of these cues. Evaluating how developers interpret and react to the sounds remains an open question for future work. We also plan to explore dynamic or data-driven cue generation, and to expand the range of supported events as part of further experimentation.

To support reproducibility, we provide the full source
code for this prototype at github.com/Gabriel-Darbord/
PharoSoundDesign.

Overall, this work demonstrates that adding sound to
a live programming environment like Pharo is technically
feasible, and offers a basis for exploring multimodal inter-
action in software development tools.

7. REFERENCES

[1] K. Barkati, D. Fober, S. Letz, Y. Orlarey, Two Recent Extensions to the FAUST Compiler, *Proceedings of the Linux Audio Conference*, 2011.

[2] T. Bi, X. Xia, D. Lo, J. Grundy, T. Zimmermann, D. Ford, Accessibility in Software Practice: A Practitioner's Perspective, *ACM Transactions on Software Engineering and Methodology*, 31(4):1–10, 2022.

[3] S. Brewster, P. Wright, and A. Edwards, An Evaluation of Earcons for Use in Auditory Human-Computer Interfaces, *Proceedings of the SIGCHI Conference on Human Factors in Computing Systems*, pp. 222–227, 1994.

<footnote n="7">⁷ With particular attention to their informativeness, salience, and per-
ceptual clarity.</footnote>
[4] D. Cipriani, A. Anatrini, S. Jordan Montaño, Phausto: Embedding the Faust compiler in the Pharo world, *Proceedings of the 4th International Faust Conference (IFC 2024)*, Nov 2024, Turin, Italy. https://hal.archives-ouvertes.fr/hal-04837510

[5] D. Cipriani, N. Palumbo, S. Jordan Montaño, S. Ducasse, Phausto: Fast and Accessible DSP Programming for Sound and Music Creation in Pharo, *Proceedings of the International Workshop on Smalltalk Technologies 2024 (IWST 2024)*, 2024.

[6] Csapó, A. (2011). Overview of auditory representation. In T. Hermann, A. Hunt, J. G. Neuhoff (Eds.), *The Sonification Handbook* (pp. 63–85). Berlin: Logos Verlag.

[7] S. Ducasse, G. Rakic, S. Kaplar, Q. Ducasse, Pharo 9 by Example, *Square Brackets Association*, 2022.

[8] International Organization for Standardization. ISO 9241-112:2017 - Ergonomics of human-system interaction, *ISO*, 2017. Available at: https://www.iso.org/standard/64875.html.

[9] S. Jordan Montaño, J.P. Sandoval Alcocer, G. Polito, S. Ducasse, P. Tesone, MethodProxies: A Safe and Fast Message-Passing Control Library, *Proceedings of the International Workshop on Smalltalk Technologies 2024 (IWST 2024)*, co-located with the 30th ESUG Conference, Lille, France, July 8–11, 2024.

[10] G. Kramer (Ed.), *Auditory Display: Sonification, Audification and Auditory Interfaces*, Addison-Wesley, Reading, MA, 1994.

[11] M. Nees and B. Walker, Theory of Sonification, in *Principles of Sonification: An Introduction to Auditory Display and Sonification*, T. Hermann, A. Hunt, and J. G. Neuhoff (Eds.), Logos Verlag Berlin, pp. 9–39, 2012.

[12] Y. Orlarey, D. Fober, S. Letz, FAUST: An Efficient Functional Approach to DSP Programming, *New Computational Paradigms for Computer Music*, Editions Delatour France, 2009, pp. 65–96. https://hal.science/hal-02159014

[13] L. Renggli, Writing Parsers with PetitParser, Available at: https://www.lukas-renggli.ch/blog/petitparser-1.

[14] G. Polito, S. Ducasse, P. Tesone, T. Brunzie, Unified FFI - Calling Foreign Functions from Pharo, *Square Brackets Association*, 2020.

[15] D.A. Sumikawa, Guidelines for the Integration of Audio Cues into Computer User Interfaces, *Naval Ocean Systems Center Technical Report*, NOSC-1043, 1985.

[16] L. Todd, Pidgins and Creoles, *Routledge*, London, 1990.

[17] G. Wang, P. Cook, ChucK: A Programming Language for On-the-fly, Real-time Audio Synthesis and Multimedia, *ACM Multimedia 2004 - Proceedings of the 12th ACM International Conference on Multimedia*, pp. 812–815, 2004.