A (partial) taxonomy of software applications devoted to sounds is presented. For each category of software applications, an abstract model is proposed and actual implementations are evaluated with respect to this model.

Nyquist is a programming language for sound synthesis and music composition. Nyquist has evolved from a text-only programming language to include an integrated development environment (IDE) that adds graphical support for many tasks. Nyquist is also hosted by Audacity, a widely used audio editor that can invoke Nyquist functions written in the form of scripted plug-ins. This article shows by example how task-oriented interface design can augment a text-based language. 1.

Nyquist is an interactive language for music composition and sound synthesis. Features of Nyquist include: (1) a full interactive environment based on Lisp, (2) no distinction between the “score ” and the “orchestra, ” (3) support for behavioral abstraction, (4) the ability to work both in terms of actual and perceptual start and stop times, and (5) a time- and memory-efficient implementation.

We begin with a functional reactive programming (FRP) model in which every program is viewed as a signal function that converts a stream of input values into a stream of output values. We observe that objects in the real world – such as a keyboard or sound card – can be thought of as signal functions as well. This leads us to a radically different approach to I/O – instead of treating real-world objects as being external to the program, we expand the sphere of influence of program execution to include them within the program. We call this virtualizing real-world objects. We explore how even virtual objects, such as GUI widgets, and non-local effects, such as are needed for debugging (using something that we call a “wormhole”) and random number generation, can be handled in the same way. Our methodology may at first seem naïve – one may ask how we prevent a virtualized device from being copied, thus potentially introducing non-determinism as one part of a program competes for the same resource as another. To solve this problem, we introduce the notion of a resource type that assures that a virtualized object is not duplicated and that I/Oandnon-localeffectsaresafe. Resourcetypesalsoprovideadeeperleveloftransparency: