You are on page 1of 773

The SuperCollider Book

edited

by

Scott

Wilson, David Cottle, and Nick Collins

The MIT Press

Cambridge, Massachusetts
London, England

Contents

Foreword ix
James McCartney
Introduction xiii
Scott Wilson, David Cottle, and Nick Collins
Tutorials

1
1
2
3
4

Advanced Tutorials
5
6
7
8

Beginner’s Tutorial 3
David Cottle
The Unit Generator 55
Joshua Parmenter
Composition with SuperCollider 81
Scott Wilson and Julio d’Escriván
Ins and Outs: SuperCollider and External Devices 105
Stefan Kersten, Marije A. J. Baalman, and Till Bovermann
125
Programming in SuperCollider 127
Iannis Zannos
Events and Patterns 179
Ron Kuivila
Just-in-Time Programming 207
Julian Rohrhuber and Alberto de Campo
Object Modeling 237
Alberto de Campo, Julian Rohrhuber, and Till Bovermann

vi

Contents

Platforms and GUI

271

9
10
11
12

Practical Applications
13

14
15
16
17
18

Mac OSX GUI 273
Jan Trützschler von Falkenstein
SwingOSC 305
Hanns Holger Rutz
SuperCollider on Windows 339
Christopher Frauenberger
“Collision with the Penguin”: SuperCollider on Linux
Stefan Kersten and Marije A. J. Baalman
379

Sonification and Auditory Display in SuperCollider 381
Alberto de Campo, Julian Rohrhuber, Till Bovermann, and Christopher
Frauenberger
Spatialization with SuperCollider 409
Marije A. J. Baalman and Scott Wilson
Machine Listening in SuperCollider 439
Nick Collins
Microsound 463
Alberto de Campo
Alternative Tunings with SuperCollider 505
Fabrice Mogini
Non-Real-Time Synthesis and Object-Oriented Composition 537
Brian Willkie and Joshua Parmenter

Projects and Perspectives
19
20

21
22
23

355

573

A Binaural Simulation of Varèse’s Poème Électronique 575
Stefan Kersten, Vincenzo Lombardo, Fabrizio Nunnari, and Andrea Valle
High-Level Structures for Live Performance: dewdrop_lib and
chucklib 589
James Harkins
Interface Investigations 613
Thor Magnusson
SuperCollider in Japan 629
Takeko Akamatsu
Dialects, Constraints, and Systems within Systems 635
Julian Rohrhuber, Tom Hall, and Alberto de Campo

vii

Contents

Developer Topics
24
25
26

657
The SuperCollider Language Implementation
Stefan Kersten
Writing Unit Generator Plug-ins 691
Dan Stowell
Inside scsynth 721
Ross Bencina

Appendix: Syntax of the SuperCollider Language
Iannis Zannos
Subject Index 745
Code Index 751

659

741

Foreword
James McCartney

Why use a computer programming language for composing music? Specifically, why
use SuperCollider? There are several very high-level language environments for
audio besides SuperCollider, such as Common Music, Kyma, Nyquist, and Patchwork. These all demonstrate very interesting work in this area and are worth looking into. SuperCollider, though, has the unique combination of being free, well
supported, and designed for real time. It is a language for describing sound processes. SuperCollider is very good at allowing one to create nice sounds with minimal
effort, but more important, it allows one to represent musical concepts as objects, to
transform them via functions or methods, to compose transformations into higherlevel building blocks, and to design interactions for manipulating music in real time,
from the top-level structure of a piece down to the level of the waveform. You can
build a library of classes and functions that become building blocks for your working
style and in this way make a customized working environment. With SuperCollider,
one can create many things: very long or infinitely long pieces, infinite variations of
structure or surface detail, algorithmic mass production of synthesis voices, sonification of empirical data or mathematical formulas, to name a few. It has also been
used as a vehicle for live coding and networked performances. Because of this openendedness, early on, I often felt it difficult to know how best to write the documentation. There were too many possible approaches and applications.
Thus, I am pleased that there will now be a book on SuperCollider, and the best
part of it for me is that I have not had to do much of the hard work to get it done.
Since I made SuperCollider open source, it has taken on a life of its own and become
a community-sustained project as opposed to being a project sustained by a single
author. Many people have stepped up and volunteered to undertake tasks of documentation, porting to other operating systems, interfacing to hardware and software, writing new unit generators, extending the class library, maintaining a Web
site, mailing lists, and a wiki, fixing bugs, and, finally, writing and editing the chapters of this book. All of these efforts have resulted in more features, better documentation, and a more complete, robust, and bugfree program.

x

James McCartney

SuperCollider came about as the latest in a series of software synthesis languages
that I have written over the years. I have been interested in writing software to synthesize electronic music ever since I was in high school. At that time, I had written
on a piece of notebook paper a set of imaginary subroutine calls in BASIC for implementing all of the common analog synthesizer modules. Of course, doing audio
synthesis in BASIC on the hardware of that time was completely impractical, but the
idea had become a goal of mine. When I graduated college, I went to have a look at
E-mu in California and found that it was operating out of a two-story house. I figured that the synthesizer industry was a lot smaller than I had imagined and that I
should rethink my career plans.
The first software synthesizer I wrote was a graphical patching environment called
Synfonix that generated samples for the Ensoniq Mirage sampling keyboard using a
Macintosh computer. I attempted to sell this program but sold only two copies, one
to Ivan Tcherepnin at Harvard and another to Mark Polishook. A business lesson I
learned from this is not to sell a product that requires purchasers to already own two
niche products. The intersection of two small markets is near zero.
In 1990, I wrote a program called Synth-O-Matic that I used personally but never
meant to distribute, even though one copy I gave to a friend got circulated. I created
this program after learning CSound and deciding that I never wanted to actually
have to use CSound’s assembly-language-like syntax. Synth-O-Matic had a more
expression-oriented syntax for writing signal flow graphs and a graphical user interface for editing wave tables. I used this program on and off, but it was quite slow so
I stopped using it, for the most part, in favor of hardware synthesizers.
It wasn’t until the PowerPC came out that it became practical to do floating-point
signal processing in real time on a personal computer. At the time I had been working on music for a modern dance piece, using Synth-O-Matic to do granular synthesis.
It was taking a long time to generate the sound, and I was running behind schedule
to get the piece done. On the day in March 1994 when the first PowerPC-based machine came out, I went and bought the fastest one. I recompiled my code, and it ran
32 times faster. I was then able to complete the piece on time. I noticed that my code
was now running faster than real time, so I began working on a program designed
to do real-time synthesis. Around this time I got a note in the mail from Curtis
Roads, who had apparently gotten one of the circulating copies of Synth-O-Matic,
encouraging me to further develop the program. So I took the Synth-O-Matic engine
and combined it with the Pyrite scripting language object which I had written for
MAX. This became SuperCollider version 1, which was released in March 1996.
The first two orders were from John Bischoff and Chris Brown of The Hub.
The name “SuperCollider” has an amusing origin. During the early 1990s I
worked in the Astronomy Department of the University of Texas at Austin on the
Hubble Space Telescope Astrometry Science Team, writing software for data analysis

xi

Foreword

and telescope observation planning. On the floors below my office was the Physics
Department, some of the members of which were involved in the Superconducting
Super Collider project. In 1993, Congress cut the funding for the project, and there
were many glum faces around the building after that. I had been thinking about this
merging, or “collision,” if you will, of a real-time synthesis engine with a high-level
garbage collected language, and it seemed to me that it was an experiment that
would likely fail, so I named it after the failed Big Science project of the day. Except
that the experiment didn’t fail. To my surprise, it actually worked rather well.
The version 1 language was dynamically typed, with a C-like syntax, closures borrowed from Scheme, and a limited amount of polymorphism. After using version 1
for a couple of years, and especially after a project on which I was invited by Iannis
Zannos to work on a concert in an indoor swimming pool in Berlin, I realized that
it had severe limitations on its ability to scale up to create large working environments. So I began working on version 2, which borrowed heavily from Smalltalk. It
was for the most part the same as the language described in this book except for the
synthesis engine and class library, which have changed a great deal.
The goal of SuperCollider version 2 and beyond was to create a language for describing real-time interactive sound processes. I wanted to create a way to describe categories of sound processes that could be parameterized or customized. The
main idea of SuperCollider is to algorithmically compose objects to create soundgenerating processes. Unit generators, a concept invented by Max Matthews for his
Music N languages, are very much like objects and are a natural fit for a purely
object-oriented Smalltalk-like language.
In 2001 I was working on version 3 of SuperCollider, and because of the architecture of the server, it was looking like it really should be open source, so that anyone
could modify it however they liked. I was (barely) making a living at the time selling
SuperCollider, so the decision to give it away was a difficult one to make. But financially it was looking like I would need a “real” job soon, anyway. I was also worried
that the period of self-employment on my résumé would begin looking suspect to
potential employers. Ultimately, I did get a job, so I was able to open source the
program. On the day that I made all of my previously copyright-protected programs
free, my Web site experienced an eightfold increase in traffic. So obviously there was
a lot of interest in an open source audio language and engine, especially one that is
free.
I hope that this book will enable and inspire the reader to apply this tool in useful
and interesting ways. And I hope to hear and enjoy the results!

Introduction
Scott Wilson, David Cottle, and Nick Collins

Welcome to The SuperCollider Book. We’re delighted to present a collection of tutorials, essays, and projects that highlight one of the most exciting and powerful
audio environments. SuperCollider (SC to its friends) is a domain-specific programming language specialized for sound but with capabilities to rival any generalpurpose language. Though it is technically a blend of Smalltalk, C, and ideas from a
number of other programming languages, many users simply accept SuperCollider
as its own wonderful dialect, a superlative tool for real-time audio adventures. Indeed, for many artists, SuperCollider is the first programming language they learn,
and they do so without fear because the results are immediately engaging; you can
learn a little at a time in such a way that you hardly notice that you’re programming
until it’s too late and you’re hooked! The potential applications in real-time interaction, installations, electroacoustic pieces, generative music, audiovisuals, and a host
of other possibilities make up for any other qualms. On top of that, it’s free, powerful, and open source, and has one of the most supportive and diverse user and developer communities around.
Pathways
This book will be your companion to SuperCollider; some of you will already have
experience and be itching to turn to the many and varied chapters further on from
this point. We’ll let you follow the book in any order you choose! But we would like
to take care to welcome any newcomers and point them straight in the direction of
chapter 1, which provides a friendly introduction to the basics. For those on Windows or Linux it may be read together with chapter 11 or 12, respectively, which
cover some of the cross-platform installation issues. From there we suggest beginners continue through until chapter 4, as this path will provide you with some basic
skills and knowledge which can serve as a foundation for further learning.
For more advanced users, we suggest you look at the more “topics”-oriented
chapters which follow. These chapters aren’t designed to be read in any particular

xiv

Scott Wilson, David Cottle, and Nick Collins

order, so proceed with those of particular interest and relevance to you and your
pursuits. Naturally we have referred to other chapters for clarification where necessary and have tried to avoid duplication of materials except where absolutely crucial
for clarity.
These “topics” chapters are divided into sections titled Advanced Tutorials, Platforms and GUI, and Practical Applications. They begin with chapter 5, “Programming in SuperCollider,” which provides a detailed overview of SuperCollider as a
programming language. This may be of interest to beginners with a computer science
background who’d rather approach SC from a language design and theory perspective than through the more user-friendly approach in chapter 1. Chapters on a variety
of subjects follow, including sonification, spatialization, microsound, GUIs, machine
listening, alternative tunings, and non-real-time synthesis.
Following these chapters is a section for intermediate and advanced users titled
Projects and Perspectives. The material therein provides examples of how SuperCollider has been used in the real world. These chapters also provide some philosophical insight into issues of language design and its implications (most specifically
in chapter 23, “Dialects, Constraints, and Systems-Within-Systems”). This sort of
intellectual pursuit has been an important part of SuperCollider’s development; SC
is a language that self-consciously aims for good design, and to allow and encourage
elegance, and even beauty, in the user’s code. Although this might seem a little abstract at first, we feel that this sets SC apart from other computer music environments and that as users advance, awareness of such things can improve their code.
Finally, there is a section titled Developer Topics, which provides detailed “under
the hood” information on SC. These chapters are for advanced users seeking a
deeper understanding of the SC and its workings and for those wishing to extend SC,
for instance, by writing custom unit generator plug-ins.
Code Examples and Text Conventions
Initially SuperCollider was Mac only, but as an open source project since 2001, it
has widened its scope to cover all major platforms, with only minor differences between them. Most code in this book should run on all platforms with the same results, and we will note places where there are different mechanisms in place; most of
the time, the code itself will already have taken account of any differences automatically. For instance, SC includes cross-platform GUI classes such as View, Slider,
and Window. These will automatically redirect to the correct GUI implementation,
either Cocoa (on Mac OSX; see chapter 9) or SwingOSC (on all platforms; see chapter 10). However, there are some differences in the programming editor environments (such as available menu items) and the keyboard shortcuts. You are referred

xv

Introduction

as well to the extensive Help system that comes with the SuperCollider application;
a Help file on keyboard Shortcuts for the various platforms is prominently linked
from the main Help page.
Just to note, when you come across keyboard shortcuts in the text, they’ll appear
like this: [enter] designates the “enter” (and not the “return”) key, [ctrl+a] means the
control key plus the “a” key, and so on. Furthermore, all text appearing in the FRGH
IRQW will almost always be valid SuperCollider code (very occasionally there may be
exceptions for didactic purposes, such as here). You will also encounter some special
SuperCollider terms (e.g., Synth, SynthDef, and Array) that aren’t in code font and
are discussed in a friendly manner; this is because they are ubiquitous concepts and
it would be exhausting to have them in the code font every time. You may also see
them appearing with a capital letter (i.e., Synths), or all lower case (synths), depending again on how formal we are being. Anyway, if you’re new to SuperCollider, don’t
worry about this at all; chapter 1 will start you on the righteous path, and you’ll
soon be chatting about Synths and UGens like the rest of us.
The Book Web Site
This brings us to the accompanying Web site for the book (<http://supercolliderbook
.net>), which contains all the code reproduced within, ready to run, as well as download links to the application itself, its source code, and all sorts of third-party extras,
extensions, libraries, and examples. A standardized version of SuperCollider is used
for the book, SuperCollider 3.4, for which all book code should work without trouble. Of course, the reader may find it productive to download newer versions of
SuperCollider as they become available, and it is our intention to provide updated
versions of the example code where needed. Although we can make no hard promises, in this fast-paced world of operating system shifts, that the code in this book
will remain eternally correct—the ongoing development and improvement of environments such as SuperCollider are a big part of what makes them so exciting—
we’ve done our best to present you with a snapshot of SuperCollider that should
retain a core validity in future years.
Final Thoughts
Please be careful with audio examples; there is of course the potential to make noises
that can damage your hearing if you’re not sensible with volume levels. Until you
become accustomed to the program, we suggest you start each example with the
volume all the way down, and then slowly raise it to a comfortable level. (And if
you’re not getting any sound, remember to check if you’ve left the monitors off or

xvi

Scott Wilson, David Cottle, and Nick Collins

the computer audio muted.) Some examples may use audio input and have the potential to feedback unless your monitoring arrangements are correct. The easiest way
to deal with such examples is to monitor via headphones.
We couldn’t possibly cover everything concerning SuperCollider, and there are
many online resources to track down new developments and alternative viewpoints,
including mailing lists, forums, and a host of artists, composers, technology developers, and SuperCollider maniacs with interesting pages. We have provided a few of
the most important links (at the time of writing) below, but Wikigoopedigle, or
whatever your contemporary equivalent is, will allow you to search out the current
SuperCollider 15.7 as necessary.
We’re sure you’ll have fun as you explore this compendium, and we’re also sure
you’ll be inspired to some fantastic art and science as you go. Enjoy exploring the
SuperCollider world first charted by James McCartney but since expanded immeasurably by everyone who partakes in this infinitely flexible open source project.
Primary Web Resources
Main community home page: <http://supercollider.sourceforge.net>
Application download and project site: <http://sourceforge.net/projects/
supercollider>
James McCartney’s home page: <http://www.audiosynth.com>
The venerable swiki site: <http://swiki.hfbk-hamburg.de:8888/MusicTechnology/6>
Acknowledgments
We owe a debt of gratitude to the chapter contributors and to the wider SuperCollider
community, who have supported this project. SC’s community is one of its greatest
strengths, and innumerable phone calls, e-mails, chats over cups of tea at the SC
Symposium, and many other interactions, have contributed to making this book and
SC itself stronger. We apologize to all who have put up with our insistent editing and
acknowledge the great efforts of the developers to prepare a stable SuperCollider 3.4
version for this book. A thousand thank-yous: 
GR^GRPRDULJDWRJR]DLPDVKLWDSRVWOQ`

Thanks to all at MIT Press who have assisted in the handling of our proposal and
manuscript for this book.
Thank you to friends, family, and colleagues who had to deal with us while we
were immersed in the lengthy task of organizing, editing, and assembling this book.
Editing may seem like a solitary business, but from their perspective we’re quite sure
it was a team effort!

tutorial materials. the editors would like to thank each other for support during the period of gestation. David modified his routine to include a 3 A. In any case.M. neither has ever met David in person (we sometimes wonder if he really exists!). and harebrained ideas. e-mail check to keep up with those using GMT. and we hope it brings you pleasure to read it and learn about SC. For many months. in the heat of the project. Though Scott and Nick have met on many occasions (and were co-organizers of the 2006 SuperCollider Symposium at the University of Birmingham). Now back to your exercise wheels! Finally. we’ve been working on this project for 2 years to bring the final manuscript to fruition.xvii Introduction Many thanks to our students. although it has at times been exhausting. who have served as guinea pigs for pedagogical approaches. At the time of writing. experimental developments. which imparts a celestially imposed 8-hour advantage. seeing this book through to fruition has been a pleasure. but you should see the number of e-mails we’ve sent each other. .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

This can be confusing. . as the topic of the chapter is huge and in some senses encompasses all aspects of SC.3 Composition with SuperCollider Scott Wilson and Julio d’Escriván 3. A brief and incomplete list of ways people might use SC for composition could include the following: Real-time interactive works with musicians Sound installations • Generating material for tape music composition (to be assembled later on a DAW). • • All of these activities have different requirements and suggest different approaches. and referring you to other chapters in this book where they are relevant. This chapter attempts to give the composer or sound artist some starting points for creative exploration.1 Introduction The actual process of composing. and deciding how to go about it. exploring both some abstract ideas and concrete applications. perhaps performed in real time • As a processing and synthesis tool kit for experimenting with sound • To get away from always using the same plug-ins • To create generative music programs • To create a composition or performance tool kit tailored to one’s own musical ideas. Thus we’ll take a pragmatic approach. SC doesn’t present the user with a single “preferred” way of working. for example. Naturally. People often find it hard to make the jump from modifying simple examples to producing a full-scale piece. we can’t hope to be anywhere near exhaustive. In contrast to Digital Audio Workstation (DAW) software such as Pro Tools. but it’s an inevitable side effect of the flexibility of SC. which allows for many different approaches to generating and assembling material. can be one of the most difficult things about using SuperCollider.

possibly your entire piece. You’ll recall from chapter 1 that environment variables are preceded by a tilde (~).82 Scott Wilson and Julio d’Escriván 3. With this in mind. VRPHFRGHZHPD\ZDQWWRXVHODWHU aVRPHWKLQJ ^3XOVHDU . for instance). As an example. or be adapted to generate a new version to different specifications (quad instead of stereo. With a little planning and foresight. you might be able to change that code so that it can easily be customized on the fly in live performance. you might have some code that generates a finished sound file.1 Coding for Flexibility The notion of making things that are flexible and reusable is something that we’ll keep in mind as we examine different ideas in this chapter. it may be useful to utilize environment variables which allow for global storage and are easily recalled.1.

(QY*HQDU (QYSHUFGRQH$FWLRQ.

from a GUI) in response to input from a performer. maybe an SC Luddite . however. In many cases in SC the mechanisms you use might be the same.) What kind of flexibility (or expressiveness!) is musically meaningful in your context? Does pragmatism (i. Keep in mind..` ZKHQWKHWLPHFRPHVMXVWFDOOLWE\LWVQDPHDQGSOD\LW aVRPHWKLQJSOD\ Since environment variables do not have the limited scope of normal variables. we’ll use them in this chapter for creating simple examples. 3.e. or algorithmically. you’re a hard-core experimentalist.e. but keep in mind that this could mean anything from the macro scale to the micro scale. How you do this depends upon your individual needs.2 Control and Structure When deciding how to control and structure a piece. You may have a simple list of events that need to happen at specific times. We use the term structure here when discussing this issue of how to control when and how things happen. you need to consider both practical and aesthetic issues: Who is your piece for? Who is performing it? (Maybe you. or a collection of things that can be triggered flexibly (for instance. maximum reliability) override aesthetic or other concerns (i. . that in the final version of a piece there may be good reasons for structuring your code differently.. . . Or you may need to combine multiple approaches. or you are on tenure track and need to do something technically impressive)? A fundamental part of designing a piece in SC is deciding how to control what happens when.

6\VWHP&ORFNVFKHG ^IRRSRVWOQ`. It makes use of the 6\VWHP&ORFN class. Routines. and Tasks Here’s a very simple example that shows you how to schedule something to happen at a given time.2.83 3 Composition with SuperCollider 3.1 Clocks.

using that value as the new delay time. )XQFWLRQ IRRUHSHDWVHYHU\VHFRQG 6\VWHP&ORFNVFKHG ^IRRSRVWOQ`. In this case the Function simply posts the word “foo. The first argument to the VFKHG message is a delay in seconds. and the second is a that will be evaluated after that delay. If the last thing to be evaluated in the Function returns a number. SystemClock will reschedule the Function.” but it could contain any valid SC code.

 EDUUHSHDWVDWDUDQGRPGHOD\ 6\VWHP&ORFNVFKHG ^EDUSRVWOQUDQG`.

 FOHDUDOOVFKHGXOHGHYHQWV 6\VWHP&ORFNFOHDU SystemClock has one important limitation: it cannot be used to schedule events which affect native GUI widgets on OSX. There is a shortcut for scheduling something on the AppClock immediately. For this purpose another clock exists. which is to wrap it in a Function and call GHIHU on it. FDXVHVDQRSHUDWLRQFDQQRWEHFDOOHGIURPWKLV3URFHVVHUURU 6\VWHP&ORFNVFKHG ^6&:LQGRZQHZIURQW`. called $SS&ORFN. but be aware that its timing is slightly less accurate. Generally you can use it in the same way as SystemClock.

 GHIHUUHVFKHGXOHV*8.FRGHRQWKH$SS&ORFNVRWKLVZRUNV 6\VWHP&ORFNVFKHG ^^6&:LQGRZQHZIURQW`GHIHU`.

by the way. and sliders. 7HPSR&ORFN. provides the ability to schedule events according to beats rather than in seconds. each with its own tempo. buttons. so for now. rather than to the class. just move past any bits that aren’t clear and try to focus on the topics at hand. Most of it should be pretty straightforward and intuitive. Unlike the clocks we’ve looked at so far. but there’s only one each of SystemClock and AppClock. anyway. By varying . Another Clock subclass. we won’t worry too much about the nitty-gritty details of it. you need to create an instance of TempoClock and send sched messages to it. This is because you can have many instances of TempoClock. so although we’ll see some GUI code in a few of the examples in this chapter. GUI. This topic is covered in detail in chapters 9 and 10. is short for Graphical User Interface and refers to things such as windows.

Here’s a simple example. W 7HPSR&ORFNQHZPDNHDQHZ7HPSR&ORFN WVFKHG ^+HOORSRVWOQ`.84 Scott Wilson and Julio d’Escriván a TempoClock’s tempo (in beats per second). you can change the speed.

 .

The next time you evaluate the Routine. and in fact you can use one almost anywhere you’d use a Function. WWHPSR WZLFHDVIDVW WFOHDU TempoClock also allows beat-based and bar-based scheduling. it picks up where it left off. so it can be particularly useful when composing metric music. you use the yield method to return a value and pause execution. (See the TempoClock Help file for more details. U 5RXWLQH ^ IRR\LHOG EDU\LHOG `.) Now let’s take a look at Routines. A 5RXWLQH is like a Function that you can evaluate a bit at a time. Within a Routine.

 .

the Routine will be rescheduled. U 5RXWLQH ^ IRRSRVWOQ \LHOGUHVFKHGXOHDIWHUVHFRQG EDUSRVWOQ \LHOG IRREDUSRVWOQ `. UYDOXHIRR UYDOXHEDU UYDOXHZH YHUHDFKHGWKHHQGVRLWUHWXUQVQLO Routine has a commonly used synonym for YDOXH. and yield a number. if you evaluate a Routine in a Clock. Now here’s the really interesting thing: since a Routine can take the place of a Function. Although “next” might make more sense semantically with a Routine. “value” is sometimes preferable. which is QH[W. for reasons we’ll explore below. just as in the SystemClock example above.

 6\VWHP&ORFNVFKHG U.

 .

.

85 3 Composition with SuperCollider )HUPDWD VERRW U 5RXWLQH ^  [ 6\QWK ?GHIDXOW>IUHTPLGLFSV@.

  ZDLW   [UHOHDVH .

  \ 6\QWK ?GHIDXOW>IUHTPLGLFSV@.

  :DLWLQJSRVWOQ  QLO\LHOGIHUPDWD   \UHOHDVH .

  ] 6\QWK ?GHIDXOW>IUHTPLGLFSV@.

  ZDLW  ]UHOHDVH `.

 .

thus “releasing” the fermata. ^ VRPHWKLQJSRVWOQ ZDLW VRPHWKLQJHOVHSRVWOQ `IRUN .1 is a (slightly) more musical example that demonstrates a fermata of arbitrary length. which is a commonly used shortcut for creating a Routine and playing it in a Clock. Functions understand a message called IRUN. a synonym for \LHOG. which is a shortcut for scheduling it in a clock. and of Routine’s SOD\ method. so you’ll need to call play again when you want to continue. GRWKLVWKHQZDLWIRUWKHIHUPDWD USOD\ IHHOWKHVZHHWWRQLF USOD\ Figure 3. This makes use of ZDLW. By yielding nil at a certain point. the clock doesn’t reschedule.1 A simple Routine illustrating a musical use of yield. Figure 3.

This time we’ll use a 7DVN. which you may remember from chapter 1.2 is a similar example with a simple GUI control. A Task works almost the same way . Figure 3.

86 Scott Wilson and Julio d’Escriván W 7DVN ^  ORRS ^ ORRSWKHZKROHWKLQJ   GR ^ GRWKLVWLPHV    [UHOHDVH .

    [ 6\QWK ?GHIDXOW>IUHTPLGLFSV@.

    ZDLW    [UHOHDVH .

    [ 6\QWK ?GHIDXOW>IUHTPLGLFSV@.

    ZDLW   `.

PZDLWLQJIRU\RXWRSUHVVUHVXPHSRVWOQ   QLO\LHOGIHUPDWD   [UHOHDVH .   .

   [ 6\QWK ?GHIDXOW>IUHTPLGLFSV@.

   ZDLW   [UHOHDVH  `.

 `.

 Z :LQGRZQHZ 7DVN([DPSOH5HFW .

IURQW
ZYLHZGHFRUDWRU )ORZ/D\RXW ZYLHZERXQGV


%XWWRQQHZ Z5HFW 

VWDWHVB >>3OD\5HVXPH&RORUEODFN
&RORUFOHDU@@

 
DFWLRQB ^WUHVXPH 

`


%XWWRQQHZ Z5HFW 

VWDWHVB >>3DXVH&RORUEODFN&RORUFOHDU@@

 
DFWLRQB ^WSDXVH`


%XWWRQQHZ Z5HFW 

VWDWHVB >>)LQLVK&RORUEODFN&RORUFOHDU@@

 
DFWLRQB ^  

WVWRS  

[UHOHDVH 

   ZFORVH  `.

 .

.2 Using Task so you can pause the sequence. Figure 3.

You can nest Tasks and Routines or combine fixed scheduling with triggers. such as the ability to pause.4 demonstrates two simple Patterns: 3VHT and 3[UDQG.) As an aside. we will not explore their workings in great detail at this point.1 Since all objects understand “value” (most simply return themselves). it can be almost anything. but instead of proceeding through it in order. in short. Once you have a Stream. you can get values from it by using the QH[W or YDOXH messages. as well as adding some random events. you can control events in time in pretty complicated ways. The trigger needn’t be from a GUI button.) Patterns are powerful because they are “reusable. a random element is selected each time. but it is worth saying that Patterns often provide a convenient way to produce a Stream of values (or other objects). anything you like. you can substitute any object (a )XQFWLRQ. As well. just as with a Routine. UUHVHW 3. for instance. Patterns provide a high-level abstraction based on Streams of events and values. a Routine is a type of Stream as well. audio input. (Chapter 6 will go into more detail regarding this. Figure 3. it prevents you from accidentally calling play twice. Since Patterns and Streams are discussed in chapter 6.3 is an example that adds varying tempo to the mix. (See chapter 15.” and many Streams can be created from 1 Pattern template. The “x” indicates that no individual value will be selected twice in a row. Pseq specifies an ordered sequence of objects (here numbers used as durations of time between successive events) and a number of repetitions (in this case an infinite number. in this case using the DV6WUHDP message. the YDOXH message above demonstrates an opportunity for polymorphism. indicated by the special value LQI). Patterns are like templates for producing Streams of values. but is meant to be played only with a Clock. You can reset a Task or Routine by sending it the UHVHW message. Pxrand also has a list (used here as a collection of pitches). and that they can be usefully combined with the methods shown above. Note that the example above demonstrates both fixed scheduling and waiting for a trigger to continue. a . A Task provides some handy advantages.2. and returning to the idea of flexibility. which is a fancy way of saying that different objects understand the same message.87 3 Composition with SuperCollider that a Routine does. as you may have guessed.2 Other Ways of Controlling Time in SC There are 2 other notable methods of controlling sequences of events in SC: Patterns and the Score object.) By combining all of these resources. Try playing with the various buttons and see what happens. it must be converted into a 6WUHDP. (In fact. Figure 3. In order to use a Pattern.

88 Scott Wilson and Julio d’Escriván U 5RXWLQH ^  F 7HPSR&ORFNQHZPDNHD7HPSR&ORFN  VWDUWD ZREEO\ ORRS  W 7DVN ^   ORRS ^    [UHOHDVH .

    [ 6\QWK ?GHIDXOW>IUHTPLGLFSVDPS@.

    ZDLW    [UHOHDVH .

    [ 6\QWK ?GHIDXOW>IUHTPLGLFSVDPS@.

    UUDQG .

ZDLWUDQGRPZDLWIURPWRVHFRQGV   `.

  `F.

XVHWKH7HPSR&ORFNWRSOD\WKLV7DVN  WVWDUW  QLO\LHOG   QRZDGGVRPHQRWHV  \ 6\QWK ?GHIDXOW>IUHTPLGLFSVDPS@.

  QLO\LHOG  \UHOHDVH .

  \ 6\QWK ?GHIDXOW>IUHTPLGLFSVDPS@.

  FWHPSR GRXEOHWLPH  QLO\LHOG  WVWRS\UHOHDVH .

[UHOHDVH .

VWRSWKH7DVNDQG6\QWKV `.

 .

. UQH[WVWDUWORRS UQH[WILUVWQRWH UQH[WVHFRQGQRWHORRSJRHV GRXEOHWLPH UQH[WVWRSORRSDQGIDGH Figure 3.3 Nesting Tasks inside Routines.

89 3 Composition with SuperCollider UDQGRPQRWHVIURPO\GLDQEVFDOH S 3[UDQG >@LQI.

DV6WUHDP RUGHUHGVHTXHQFHRIGXUDWLRQV T 3VHT >@LQI.

DV6WUHDP W 7DVN ^  ORRS ^   [UHOHDVH .

   [ 6\QWK ?GHIDXOW>IUHTSYDOXHPLGLFSV@.

   TYDOXHZDLW  `.

 `.

 WVWDUW .

WVWRS[UHOHDVH .

5RXWLQH. In any case. so since the OSC messages which the server understands are outlined in the Server Command Reference Help file. if you find over time that you prefer to work in “messaging style” rather than “object style. The second method of controlling event sequences is the 6FRUH object.5. (See figure 3. That is. Score is essentially an ordered list of times and 26& commands. Since S and T are evaluated each time through the loop. we’ll just refer you there if you’d like to explore further. and can be useful for anything from generic compositions to algorithmically variable compositions. OSC stands for Open Sound Control.) that will return an appropriate value for S or T in the example above. it’s even possible to do this while the 7DVN is playing. What you probably didn’t realize is that it is possible to work with OSC messages directly.4 Using Patterns within a Task. This takes the form of nested Arrays. This is a rather large topic. Figure 3.” you may find 6FRUH useful.6 provides a short example. rather than through objects such as Synths. Score also provides some handy functionality for non-real-time synthesis (see chapter 18). > >WLPH>FPG@@ >WLPH>FPG@@  @ As you’ll recall from chapter 2.) Taking advantage of polymorphism in ways like this can provide great flexibility. Figure 3. etc. which is the network protocol SC uses for communicating between language and server. a number. .

90 Scott Wilson and Julio d’Escriván S DFRQVWDQWQRWH T 3VHT >@LQI.

DV6WUHDPRUGHUHGVHTXHQFHRIGXUDWLRQV W 7DVN ^  ORRS ^   [UHOHDVH .

   [ 6\QWK ?GHIDXOW>IUHTSYDOXHPLGLFSV@.

   TYDOXHZDLW  `.

 `.

 WVWDUW .

QRZFKDQJHS S 3VHT >@LQI.

DV6WUHDPWRD3DWWHUQGRUHPL S ^UUDQG .

`WRD)XQFWLRQUDQGRPQRWHVIURPD FKURPDWLFRFWDYH WVWRS[UHOHDVH .

5 Thanks to polymorphism. Figure 3. we can substitute objects that understand the same message. 6\QWK'HI 6FRUH6LQH^DUJIUHT  2XWDU   6LQ2VFDU IUHT.

 /LQHNU GRQH$FWLRQ.

.

`.

'DGG$FWLRQWDUJHW.'V\QWKDUJV >>?VBQHZ?6FRUH6LQH?IUHT@@ >>?VBQHZ?6FRUH6LQH?IUHT@@ >>?VBQHZ?6FRUH6LQH?IUHT@@ >>?FBVHW@@GXPP\FRPPDQGWRPDUNHQGRI157V\QWKHVLVWLPH @ ] 6FRUH [.DGG [ > DUJVIRUVBQHZDUHV\QWKGHIQRGH.

 .

]SOD\ Figure 3.6 Using “messaging style”: Score. .

91 3 Composition with SuperCollider KHUH VDV\QWKGHIWKDWDOORZVXVWRSOD\IURPDEXIIHUZLWKDIDGHRXW 6\QWK'HI SOD\EXI^DUJRXW EXIJDWH   2XWDU RXW   3OD\%XIDU EXI%XI5DWH6FDOHNU EXI.

ORRS.

    /LQHQNU JDWHGRQH$FWLRQ.

UHOHDVHV\QWKZKHQIDGHGRQH  .

`.

DGG ORDGDOOWKHSDWKVLQWKHVRXQGVIROGHULQWREXIIHUV aVRPH6RXQGV VRXQGV SDWK0DWFKFROOHFW^_SDWK_%XIIHUUHDG VSDWK.

` .

QRZKHUH VWKHVFRUHVRWRVSHDN H[HFXWHWKHVHRQHOLQHDWDWLPH aQRZ3OD\LQJ 6\QWK SOD\EXI>EXIaVRPH6RXQGV>@@.

 aQRZ3OD\LQJUHOHDVHaQRZ3OD\LQJ 6\QWK SOD\EXI>EXIaVRPH6RXQGV>@@.

 aQRZ3OD\LQJUHOHDVHaQRZ3OD\LQJ 6\QWK SOD\EXI>EXIaVRPH6RXQGV>@@.

 aQRZ3OD\LQJUHOHDVH IUHHWKHEXIIHUPHPRU\ aVRPH6RXQGV%XIIHUHGGR BIUHH.

a common technique when combining live performers with a “tape” part. 3. Triggering sound files. and the latter for substantial cues that you wouldn’t want to keep in RAM. is easily achieved in SuperCollider. Here’s a very simple example which loads 2 files into RAM and plays them: aP\%XIIHU %XIIHUUHDG VVRXQGVDZONZDY. The former is convenient for short files.3 Cue Players Now let’s turn to a more concrete example. One question you need to ask is whether to play the sounds from RAM or stream them from hard disk. There are several classes (both in the standard distribution of SuperCollider and within extensions by third-party developers) that help with these 2 alternatives. Figure 3. to fully fledged GUIs that completely hide the code from the user.2. There are many approaches to the construction of cue players.7 Executing one line at a time. These range from a list of individual lines of code that you evaluate one by one during a performance.

7 presents an .ORDGDVRXQG aP\%XIIHUSOD\SOD\LWDQGQRWLFHLWZLOOUHOHDVHWKHQRGHDIWHU SOD\LQJ Buffer’s play method is really just a convenience method. such as fade in or out. though. and we’ll probably want to do something fancier. Figure 3.

92 Scott Wilson and Julio d’Escriván 6\QWK'HI SOD\EXI^DUJRXW EXIJDWH   2XWDU RXW   3OD\%XIDU EXI%XI5DWH6FDOHNU EXI.

ORRS.

   /LQHQNU JDWHGRQH$FWLRQ.

    ZLWK GRQH$FWLRQ ZHUHOHDVHV\QWKZKHQIDGHLVGRQH .

`.

DGG aVRPH6RXQGV VRXQGV SDWK0DWFKFROOHFW^_SDWK_%XIIHUUHDG VSDWK.

` Q DFRXQWHU KHUH VRXU*8.FRGH Z :LQGRZQHZ 6LPSOH&XH3OD\HU5HFW .

.

IURQW ZYLHZGHFRUDWRU )ORZ/D\RXW ZYLHZERXQGV.

 WKLVZLOOSOD\HDFKFXHLQWXUQ %XWWRQQHZ Z5HFW .

.

VWDWHVB >>3OD\&XH&RORUEODFN &RORUFOHDU@@.

DFWLRQB ^  LI QaVRPH6RXQGVVL]H^   LI Q ^aQRZ3OD\LQJUHOHDVH`.

   aQRZ3OD\LQJ 6\QWK SOD\EXI>EXIaVRPH6RXQGV>Q@@.

Q Q  `.

 `.

 WKLVVHWVWKHFRXQWHUWRWKHILUVWFXH %XWWRQQHZ Z5HFW .

.

VWDWHVB >>6WRS5HVHW&RORUEODFN &RORUFOHDU@@.

DFWLRQB ^Q aQRZ3OD\LQJUHOHDVH`.

 IUHHWKHEXIIHUVZKHQWKHZLQGRZLVFORVHG ZRQ&ORVH ^aVRPH6RXQGVGR BIUHH.

` .

Q UGens (the latter allows for variable-speed streaming). You can of course have lines of many statements. example which uses multiple cues in a particular order. which can all be executed at once. Figure 3. It uses the 3OD\%XI UGen. statements. The middle 2 lines of the latter section of figure 3. but you might instead want something a little more elaborate or user-friendly. (Lines are separated by carriage returns. played by executing the code one line at a time.8 Playing cues with a simple GUI. SC also allows for streaming files in from disk using the 'LVN. which you may remember from chapter 1.Q and 9'LVN. There are also a number of . by semicolons.8 is a simple example with a GUI.) The “1 line at a time” approach is good when developing something for yourself or an SC-savvy user.7 consist of 2 statements. Figure 3. and thus do 2 things when you press the enter key to execute.

you may need to deal with multiple mono cues.) After executing this. Using the methods SUHSDUH)RU5HFRUG SDWK. so we’ll look at a few issues related to generating and capturing material in SC and give a concrete example of an approach you might want to adapt for your own purposes.93 3 Composition with SuperCollider third-party extension classes that do things such as automating the required housekeeping (e. Often. or for converting an entire piece to a distributable sound file format. for documenting a performance. The previous examples deal with mono files. Again. To illustrate this.3 Generating Sound Material The process of composition deals as much with creating sounds as it does with ordering them. you should be able to do what you can imagine (more or less!). you should have a sound file in SC’s recordings folder (see the doc for platform-specific locations) labeled with the date and time SC began recording: SC_YYMMDD_HHMMSS.10. The 6HUYHU class provides easy automated recording facilities.3.9 shows how to sort them based on a folder containing subfolders of mono channels. 3. an exhaustive discussion of all of SuperCollider’s sound-generating capabilities would far exceed the scope of this chapter. or similar (see figure 3. we will work here with sound files for the sake of convenience. however.11). 6HUYHU also provides handy buttons on the Server window (appearance or availability varies by platform) to prepare.1 Recording At some point you’re probably going to want to record SC’s output for the purpose of capturing a sound for further audio processing or “assembly” on a DAW. You may not find a commercial plug-in that will do this. (See figure 3. and start recording.Q6DPSOHU).. this is the simplest way to capture your sounds.aif. The above example uses the default recording options. Fredrik Olofsson’s 5HG'LVN. The ability to control sounds and audio processes at a low level can be great for finding your own compositional voice. but you should keep in mind that what we’re discussing could apply to more or less any synthesis or processing technique. let’s make a sound by creating an effect that responds in an idiosyncratic way to the amplitude of an input file and then record the result. but in SC. Figure 3. 3.2 Sometimes.g. On OSX it may look like this. stop. As before. For multichannel files (stereo being the most common case) it is simplest to deal with interleaved files.

The latter 3 methods must be called before SUHSDUH)RU5HFRUG. the default is to . A common case is to change the sample format. UHF+HDGHU)RUPDWB.. you can customize the recording process. UHF&KDQQHOVB. and UHF6DPSOH)RUPDWB.

94 Scott Wilson and Julio d’Escriván JDWKHUDOO\RXUIROGHUSDWKV WKLVZLOOSDWKPDWFKHDFKIROGHULQWKHFROOHFWLRQLHZHZLOOKDYHDFROOHFWLRQ RIFROOHFWLRQVRISDWKV aJURXS2ILQGLY&XH)ROGHUV VRXQGV SDWK0DWFKFROOHFW^_LWHP_ LWHPDV6\PERO .

SDWK0DWFK` 3RVWaJURXS2ILQGLY&XH)ROGHUVVHHWKHPDOO FKHFNKRZPDQ\FXHV\RXZLOOKDYHLQWKHHQG aJURXS2ILQGLY&XH)ROGHUVVL]H DXWRPDWHWKHEXIIHULQJSURFHVVIRUDOOFXHV aEXIIHUHG&XHV aJURXS2ILQGLY&XH)ROGHUVFROOHFW^_LWHPL_LWHPFROOHFW^_SDWK_ %XIIHUUHDG VSDWK.

``QRZDOORXUFXHILOHVDUHVLWWLQJLQWKHLUEXIIHUV aEXIIHUHG&XHV>@KHUHLVFXH VHHLWLQWKHSRVWZLQGRZ 3RVWaEXIIHUHG&XHV>@ SOD\WKHPDOOLQD*URXSXVLQJRXUSUHYLRXVV\QWKGHI ZHXVHELQGKHUHWRHQVXUHWKH\VWDUWVLPXOWDQHRXVO\ VELQG ^  aQRZ3OD\LQJ *URXSQHZ V.

DJURXSWRSXWDOOWKHFKDQQHOV\QWKVLQ  aEXIIHUHG&XHV>@GR ^_FXH_6\QWK SOD\EXI>EXIFXH@aQRZ3OD\LQJ.

`.

`.

 .

9 Gathering up files for multichannel cues. IDGHWKHPRXWWRJHWKHUE\VHQGLQJDUHOHDVHPHVVDJHWRWKHJURXS aQRZ3OD\LQJUHOHDVH Figure 3. .

95 3 Composition with SuperCollider VERRWPDNHVXUHWKHVHUYHULVUXQQLQJ ILUVWHYDOXDWHWKLVVHFWLRQ E %XIIHUUHDG VVRXQGVDZONZDY.

DVRXUFH VSUHSDUH)RU5HFRUGSUHSDUHWKHVHUYHUWRUHFRUG \RXPXVWGRWKLVILUVW.

.

 VLPXOWDQHRXVO\VWDUWWKHSURFHVVLQJDQGUHFRUGLQJ VELQG ^  KHUH VRXUIXQN\HIIHFW  [ ^YDUFROXPELDDPS   FROXPELD 3OD\%XIDU EORRS.

   DPS $PSOLWXGHDU FROXPELD.

 VWLFN\ DPSIROORZHU   2XWDU 5HVRQ]DU FROXPELDDPS.

.

ILOWHUIUHTIROORZVDPS   `SOD\ VUHFRUG `.

 .

VSDXVH5HFRUGLQJSDXVH VUHFRUGVWDUWDJDLQ VVWRS5HFRUGLQJVWRSUHFRUGLQJDQGFORVHWKHUHVXOWLQJVRXQGILOH Figure 3.11 A screen shot of a Server window.10 Recording the results of making sounds with SuperCollider. Figure 3. .

96 Scott Wilson and Julio d’Escriván record as 32-bit floating-point values. This has the advantage of tremendous dynamic range. VUHF6DPSOH)RUPDWB LQW. which means you don’t have to worry about clipping and can normalize later. but it’s not compatible with all audio software.

and instead consider whether the problem they’re dealing with has a general solution. SC also has non-real-time synthesis capabilities. by using the 'LVN2XW UGen. Generalizing your code can be very powerful. We might do something like this: ^ 5HVRQ]DU 'XVWDU . which may be useful for rendering CPU-intensive code. of course. Server’s automatic functionality is in fact based on this. More elaborate recording can be realized.2 Thinking in the Abstract Something that learners often find difficult to do is to stop thinking about exactly what they want to do at the moment.3. (See chapter 18. Imagine that we want to make a sound that consists of 3 bands of resonated impulses.) 3.

.

 5HVRQ]DU 'XVWDU .

.

 5HVRQ]DU 'XVWDU .

.

 UHFLSURFDOVFDOHWRHQVXUH QRFOLSSLQJ `SOD\ .

we can abstract the problem from this concrete realization and come up with a more general solution: I  Q  ^ 0L[ILOO Q^_L_5HVRQ]DU 'XVWDU . Now. through a bit of careful thinking.

I  L.

.

`.

QUHFLSURFDOVFDOHWRHQVXUHQRFOLSSLQJ `SOD\ .

but we’ve expressed it in terms of generalized instructions. We’ve . This version has an equivalent result. as you might do in a visual patching language such as Max/MSP. It shows you how to construct a Synth consisting of resonated impulses tuned in whole-number ratios rather than as an exact arrangement of objects and connections.

Now it happens that the example above is hardly shorter than the first. but look what we can do with it: I  Q  ^ 0L[ILOO Q^_L_5HVRQ]DU 'XVWDU .97 3 Composition with SuperCollider also used variables (f for frequency and n for number of resonators) to make our code easy to change. This is the great power of abstraction: by expressing something as a general solution. you can be much more flexible than if you think in terms of exact implementations.

I  L.

.

`.

QUHFLSURFDOVFDOHWRHQVXUHQRFOLSSLQJ `SOD\ .

. the morphology of the sound. Can we take sound material and examine it under another abstracted morphology? In ordinary musical terms this could mean a minor scale can be played in crescendo or diminuendo and remain a minor scale. Make me a resonator. gestures are. as software has become more accessible. One of the main advantages of a computer language is generalization. traditionally they amount to much the same thing in electronic music. it’s much easier to understand. the composer does not differentiate gesture from musical content. Make me a resonator. This may account for the computer’s being used today as a virtual analog studio.12). a compendium of its behavior. It’s like the difference between saying “Make me 50 resonators” and saying “Make me a resonator.” This way of thinking has potential applications in almost every aspect of SC. if you will. 3. By changing I and Q we’re able to come up with a much more complex variant. for example. In the traditional “tape” music studio approach. as we have seen above. Imagine what the hard-coded version would look like with 50 individual 5HVRQ] 8*HQV typed out by hand. . However. even GUI construction (see figure 3. In fact.3. But can a musical gesture exist independently of sound? In electronic music. electroacoustic and electronic composition has been a rather “manual” process. not only is the code more flexible. In electroacoustic music this can happen.3 Gestures For a long time. many sequencer software GUIs attest to this way of thinking. . when we modulate 1 sound with the . In this case. and because of that. programming may in fact be replacing this virtual splicing approach. or abstraction. it’s shorter.

98 Scott Wilson and Julio d’Escriván I  Q QXPEHURIUHVRQDWRUV W $UUD\ILOO Q^_L_ ^ 5HVRQ]DU 'XVWDU .

I  L.

.

QUHFLSURFDOVFDOHWRHQVXUHQRFOLSSLQJ `SOD\ `.

DVFUROOLQJZLQGRZVRZHGRQ WUXQRXWRIVSDFH Z :LQGRZQHZ %XWWRQV5HFW . QRZPDNHD*8.

VFUROOWUXH.

 ZYLHZGHFRUDWRU )ORZ/D\RXWQHZ ZYLHZERXQGV.

DXWROD\RXWWKHZLGJHWV QGR ^_L_ %XWWRQQHZ Z5HFW .

.

VWDWHVB > >)UHT I  L.

.

2Q&RORUEODFN&RORUZKLWH@ >)UHT I  L.

.

2II&RORUZKLWH&RORUEODFN@ @.

DFWLRQB ^DUJEXWW W>L@UXQ EXWWYDOXH .

 `.

 `.

 ZIURQW .

and then we will look at some Routines we can call up as part of a “Routine of Routines” (i. we are accustomed to hearing this in signal-processing software. If you prefer to work in a more traditional way. in a sense. so to speak). spectrum of another. you can just run the Routines with different sounds each time. a score. abstractions of “how to deliver” the musical idea. you can add elements of variability to what is normally fixed . gestures waiting for a sound. Figure 3. They are.e. In this section we would like to show how SuperCollider can be used to create “empty gestures. an advantage of doing the larger-scale organization of your piece within SC is that since you are interpreting your code during the actual performance of your piece.12 A variable number of resonators with an automatically created GUI. record them to hard disk. First we will look at some snippets of code that we can reuse in different patches. The shape of 1 sound is generalized and applied to another. However. and then assemble or sample as usual in your preferred audio editing/sequencing software..” gestures that are not linked to any sound in particular.

3. 3. You can also add elements of chance to your piece without necessarily venturing fully into algorithmic composition. as it will allow us to call up any file we opened with our file browser during the course of our session. brings us back to issues of design. and exactly what you choose to do will depend on your own needs and inclinations.4 Making “Empty” Gestures Let’s start by making a list where all our Buffers will be stored. you can always record the output to a sound file if desired. (Naturally.) This. of course. This will come in handy later on.99 3 Composition with SuperCollider at the time of playback. In the following example we open a dialogue box and can select any sound(s) on our hard disk: \RXZLOOEHDEOHWRDGGPXOWLSOHVRXQGILOHVMXVWVKLIWFOLFNZKHQ VHOHFWLQJ YDUILOHVRXQG3DWK aEXIIHUV /LVW>@ 'LDORJJHW3DWKV ^DUJSDWKV SDWKVGR ^_VRXQG3DWK_ SRVWWKHSDWKWRYHULI\WKDWLWLVWKHRQH\RXH[SHFW VRXQG3DWKSRVWOQ DGGVWKHUHFHQWO\VHOHFWHG%XIIHUWR\RXUOLVW aEXIIHUVDGG %XIIHUUHDG VVRXQG3DWK.

.

`.

`.

 .

First. let’s make a simple 6\QWK'HI so we can create Synths which play our Buffer (for example. For example. or other 6WUHDP) later on. 7DVN. For the purposes of this demonstration we will use a very simple percussive envelope. You can check to see how many Buffers are in your list so far (watch the post window!). in any 5RXWLQH. aEXIIHUVVL]H and you can see where each sound is inside your list. here is the very first sound stored in our Buffer list: aEXIIHUV>@ Now that we have our sound in a Buffer. let’s just listen to the sound to verify that it is there: aEXIIHUV>@SOD\ Now. let’s try some basic manipulations. making sure we have GRQH$FWLRQ in order to free the synth after the envelope terminates: .

100 Scott Wilson and Julio d’Escriván EXIIHUSOD\HUZLWKGRQHDFWLRQDQGFRQWURORIHQYHORSHDQGSDQQLQJ 6\QWK'HI ?VDPSOH3OD\HU^DUJRXW EXI  UDWH DW UHO SRV S6SHHG OHY  YDUVDPSOHSDQ7DPSDX[ VDPSOH 3OD\%XIDU EXIUDWH %XI5DWH6FDOHNU EXI.

.

 SDQ7 )6LQ2VFNU S6SHHG.

 DPS (QY*HQDU (QYSHUF DWUHOOHY.

GRQH$FWLRQ.

 2XWDU RXW3DQDU VDPSOHSDQ7DPS.

.

 `.

DGG .

DGG also stores it within the global 6\QWK'HVF/LE in the client app. so that its arguments can be looked up later by the Patterns and Streams system (see chapter 6). Let’s test the SynthDef: 6\QWK ?VDPSOH3OD\HU>?RXW?EXIQXPaEXIIHUV>@?UHO@. In addition to sending the def to the server. We’ll need this below. As mentioned in chapter 1. we use the DGG method here rather than one of the more low-level SynthDef methods such as VHQG.

Of course. and also play randomly from that list.25 second of the selected sound. from the list we defined earlier we could do this: 6\QWK ?VDPSOH3OD\HU>?RXW?EXIQXPaEXIIHUVFKRRVH?UHO@. For example. it plays 0. if you have made more than 1 Buffer list. As you can hear. you can play sounds from any list.

using 3UDQG or 3[UDQG). to choose which speaker a sound comes from without repeating speakers: 3[UDQG >@LQI. which specifies a geometric series. You can use this. You can also add variability by making some of them perform choices when they generate their values (e. modify the Routine to create other accel/decel Patterns by substituting different Patterns. You can. 3JHRP..g.3 Note that Patterns can be nested.13 shows a Pseq whose list consists of two Pgeoms. Remember that you can use a 7DVN or 5RXWLQH to sequence several such gestures within your piece. Figure 3. We’ll use a new Pattern here. for example. Let’s define a Routine that allows us to create a stuttering /rushing gesture in a glitch style. of course.

in . which are like a kind of dictionary of named properties and associated values. If you send the message SOD\ to a Pbind. It creates a Stream of Events. The advantage of having assigned your gestures to environment variables (using the tilde shortcut) is that now you are able to experiment in real time with the ordering. simultaneity. it will play the Stream of Events. and internal behavior of your gestures. Let’s take a quick look at 1 more important Pattern: 3ELQG.

101 3 Composition with SuperCollider  DURXWLQHIRUFUHDWLQJDULWDUGDQGRVWXWWHUZLWKSDQQLQJ\RXPXVWKDYH UXQWKHFRGHLQILJVRWKDWWKLVURXWLQHPD\ILQGVRPHVRXQGVDOUHDG\ORDGHG LQWREXIIHUV\RXFDQFKDQJHWKHLQGH[RIaEXIIHUHG&XHVWRWHVWWKHURXWLQHRQ GLIIHUHQWVRXQGV  aVWXW 5RXWLQH ^YDUGXUSRV aVWXW3DWW 3VHT >3JHRP .

3Q .

3JHRP .

@.

 aVWU aVWXW3DWWDV6WUHDP GR^ GXU aVWUQH[W GXUSRVWOQ VRZHFDQFKHFNYDOXHVRQWKHSRVWZLQGRZ aVDPSOH 6\QWK VDPSOH3OD\HU>?RXW?EXIaEXIIHUHG&XHV>@?DW ?UHO?S6SHHG@.

 GXUZDLW ` `.

 .

Here’s a simple example which makes sound using what’s called the “default” SynthDef: UDQGRPO\VHOHFWHGIUHTXHQF\GXUDWLRQVHFRQG 3ELQG ?IUHT3UDQG >@. QRZSOD\LW aVWXWSOD\ UHVHWEHIRUH\RXSOD\DJDLQ aVWXWUHVHW Figure 3.13 Making a stuttering gesture using a geometric Pattern. a fashion similar to the Clock examples above.

?GXU.

SOD\ It’s also possible to substitute Event Streams as they play. When you call SOD\ on a 3DWWHUQ. it returns an (YHQW6WUHDP3OD\HU. which actually creates the individual Events from the Stream defined by the Pattern. EventStreamPlayer allows its Stream to be substituted while it is playing. aJHVW 3ELQG ?LQVWUXPHQW?VDPSOH3OD\HU?GXU?UHO.

 aSOD\HU aJHVWSOD\PDNHLWSOD\ aSOD\HUVWUHDP 3ELQG ?LQVWUXPHQW?VDPSOH3OD\HU?GXU?UDWH 3[UDQG >@LQI.

?UHO.

DV6WUHDPVXEVWLWXWHWKH VWUHDP aSOD\HUVWRS .

the Pbind plays repeatedly at intervals specified by the \dur argument. but it will stop playing as soon as it receives nil for this or any other argument. the Pbind is able to look it up in the global library and get the information it needs about the def. Here is a Pbind making use of our accelerando Pattern to create a rushing sound: aJHVW 3ELQG ?LQVWUXPHQW?VDPSOH3OD\HU?GXU3JHRP . Since we added it above. we can also choose to work in a looping/ layering fashion.102 Scott Wilson and Julio d’Escriván If you have evaluated the expressions above. but rather the one we made earlier. Now. but more of that later). you will notice that you don’t hear the simple default SynthDef. So we can take advantage of this to make Streams that are not repetitive and thus make single gestures (of course.

 ?UHO.

of course. If you call play on it again. as we had to do with the Routine. it returned nil and the EventStreamPlayer stopped playing. you will notice that it makes the same rushing sound without the need to reset it. by nesting patterns: 3ELQG ?LQVWUXPHQW?VDPSOH3OD\HU?GXU3VHT >3JHRP . More complex gestures can be made. aJHVWSOD\ When the Stream created from the Pgeom ended. since it will return a new EventStreamPlayer each time.

 3JHRP .

@.

?UHO?S6SHHG.

SOD\ 3ELQG ?LQVWUXPHQW?VDPSOH3OD\HU?GXU3VHT >3JHRP .

 3JHRP .

@.

?UDWH3[UDQG >@LQI.

?UHO ?S6SHHG.

Let’s designate another environment variable to hold a sequence of values that we can plug in at will and change on the fly. This Pattern holds values that would work well for \dur: aUK\WKP 3VHT >QLO@.7 library (see chapter 7).SOD\ Similar things can be done with the 3GHI class from the -.

WKHQLOLVVRLWZLOO VWRS We can then plug it into a 3GHI. which we’ll call ?D: aJHVW 3GHI ?D3ELQG ?LQVWUXPHQW?VDPSOH3OD\HU?GXUaUK\WKP?UHO ?S6SHHG.

.

aUK\WKP 3VHT > QLO@. aJHVWSOD\ If we define another sequence of values we want to try.

 .

103 3 Composition with SuperCollider and then reevaluate the 3GHI. aJHVW 3GHI ?D3ELQG ?LQVWUXPHQW?VDPSOH3OD\HU?GXUaUK\WKP?UHO ?S6SHHG.

.

 we can hear that the new aUK\WKP has taken the place of the previous one. In the following example. we assign a Pattern to the rate values and obtain an interesting variation: aJHVW 3GHI ?D3ELQG ?LQVWUXPHQW?VDPSOH3OD\HU?DWW?UHO ?OHY^UUDQG . anything that is “poured” into it will come out. Notice that it played immediately. without the need for executing aJHVWSOD\. This is one of the advantages of working with the 3GHI class: once the 6WUHDP is running.

`?GXU?UDWH3VHT >3EURZQ  .

@.

.

.

Introduction to Computer Music. Below we refer you to some interesting texts that may enhance your creative investigations. 3. we can trigger them in a certain order using a 5RXWLQH. O. The latter approach is useful if we want to use a cue player for the final structuring of a piece. 2000. If we have “added” more than 1 6\QWK'HI. “Composing with Objects. We have shown that the assembly of sounds itself can become a form of synthesis. illustrated by our use of Patterns and Streams. and you will learn it much better than just by reviewing everything it can do.4 Conclusions What next? The best way to compose with SuperCollider is to set yourself a project with a deadline! In this way you will come to grips with specific things you need to know. Another approach is to review some of the classic techniques used in electroacoustic composition and try to re-create them yourself using SuperCollider. Collins. Further Reading Budón. 2010. as well as for assembling your piece in flexible ways. SuperCollider offers a variety of approaches to electronic music composition. Chichester: Wiley. Networks. 24(3): 9–22. and Time Scales: An Interview with Horacio Vaggione. . Experiments like these can be conducted by creating Patterns for any of the arguments that our 6\QWK'HI will take. It can be used for sound creation thanks to its rich offering of UGens (see chapter 2). Once we have a set of gestures we like. we can even modulate the ?LQVWUXPHQW by getting it to choose among several different options. N. or we can record them separately and load them as audio files to our audio editor.” Computer Music Journal.

291–396. York. “Programming Languages for Computer Music Synthesis. Cambridge. 1997. eds.104 Scott Wilson and Julio d’Escriván Dodge. G. and the method is what the object does in response. Loy. “The Digital Computer as a Musical Instrument. Microsound. S.” In M. G. In polymorphism the distinction becomes clear: different objects may respond to the same message with different methods. The Computer Music Tutorial. MA: MIT Press. 1985. T. 2001. 2001. MA: MIT Press. Miranda. New York: Schirmer. 17(2): 235–265. M. 2nd ed. R. MA: MIT Press.. 2. C.. Jerse.” ACM Computing Surveys (CSUR). 1994. 5(1): 51–64. Pierce. Loy. Performance. Scott Wilson’s De-Interleaver application for OSX and Jeremy Friesner’s cross-platform command line tools audio_combine and audio_split allow for convenient interleaving and deinterleaving of audio files. Mathews and J. Mathews. C. Composition. R. Audible Design: A Plain and Easy Introduction to Practical Sound Composition. Roads. Cambridge. V. Cambridge. E. and Composition. Wishart. Holtzman. Roads. 3. and Performance. Composing Music with Computers.” Computer Music Journal. 1981. 1989..” Science. . the message is the command. Notes 1. 142(3592): 553–557. pp. and T. C. “Using Generative Grammars for Music Composition. “Composing with Computers: A Survey of Some Compositional Formalisms and Music Programming Languages. and Abbott. Current Directions in Computer Music Research. V. Computer Music: Synthesis. UK: Orpheus the Pantomime. A geometric series is a series with a constant ratio between successive terms. In other words. 1996. R. A. 1963. London: Focal Press. C. You may have noticed that the terms “message” and “method” used somewhat interchangeably.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

we’ll look at something simpler. which can receive a number of floating-point data inputs (audio. The bulk of the work is C++ programming. these classes are always derived from a base class.). passing data from 1 UGen to another. Really? A UGen is a component for the synthesis server.25 Writing Unit Generator Plug-ins Dan Stowell Writing a unit generator (UGen) for SuperCollider 3 can be extremely useful. So to create a new UGen you need to create both the plug-in for the server and the class file for the language client. or sending a message over a network. accessing a buffer. defined in a plug-in. The server can incorporate the UGen into a synthesis graph. from the plug-in programmer’s point of view. You’re probably already familiar with UGens from other chapters.or control-rate signals or constant values) and produce a number of floating-point data outputs. 25. These representations allow us to define synthesis graphs in SC language (SynthDefs). When using SC language. type.2 An Aside: Pseudo UGens Before we create a “real” UGen. 25. allowing the addition of new audio generation and processing capabilities to the synthesis server. you can start to create UGens based on existing examples. as well as “side effects” such as writing to the post window. each UGen also comes with an SC class. A pseudo UGen is an SC class that “behaves like” a UGen from the user’s point of view but doesn’t . Therefore. Before creating new UGens of your own. etc. but the API (Application Programming Interface) is essentially quite simple — so even if you have relatively little experience with C/C++. let’s first consider what a UGen really is. appropriately called 8*HQ. we need to have available a representation of each UGen which provides information about its inputs and outputs (the number.1 What Is a UGen.

it just encapsulates some useful arrangement of existing units.692 Dan Stowell involve any new plug-in code. a simple reverb effect: 5HYHUE^  DU^_LQ_ YDURXW LQ RXW $OOSDVV1DU RXWUDQG. Instead. Let’s create an example.

We are free to use the full power of SC language. to choose a random delay time for our effect. with a single class method. You’ll now be able to use 5HYHUEDU within your SynthDefs.sc in your SCClassLibrary or Extensions folder. Reverb1. but we’ll improve it later. The only real requirement for a pseudo UGen is that the method returns something that can be embedded in a synth graph. Let’s test this: VERRW [ ^ YDUIUHTVRQRXW &KLUSVDWDUELWUDU\PRPHQWV IUHT (QY*HQDU (QYSHUF . ARXW ` ` This isn’t a very impressive reverb yet. then recompile. this is a class like any other. what is returned is an $OOSDVV1 applied to the input. including constructs such as UDQG. In our simple example. As you can see. just as if it were a “real” UGen. for instance. The DU method name is not special — in fact. you could use any method name (including QHZ). Copy the above code into a new file and save it as.

'XVWDU .

.

 VRQ 6LQ2VFDU IUHT.

 :HDSSO\UHYHUEWRWKHOHIWDQGULJKWFKDQQHOVVHSDUDWHO\ RXW ^5HYHUEDU VRQFXWRII.

`GXS `SOD\ V.

 .

we modify it to perform 6 similar all-pass delays in a row. We also add parameters: 5HYHUE^  DU^_LQZHW FXWRII _ YDURXW LQ GR^RXW /3)DU $OOSDVV1DU RXWUDQG. Reverb1. [IUHH You may wish to save this usage example as a rudimentary Help file.html. and we also add some LPF units in the chain to create a nice frequency roll-off. To make the reverb sound more like a reverb.

FXWRII.

` .

693 25 Writing Unit Generator Plug-ins A RXW ZHW.

 LQ  ²ZHW.

.

The programming interface is straightforward. for SinOsc. First. 2. and again existing plug-in code can be a helpful reference: all UGens are written as plug-ins — including the “core” UGens — so there are lots of code examples available. Dwhite) can be helpful as templates.3 Steps Involved in Creating a UGen 1. write the plug-in code. even if you don’t plan to release the UGen publicly. Fourth. 3. Efficiency should also be a consideration. As well as being a good place to keep the example code which you can use while developing and testing the UGen. 4. because they can be combined in many ways within a SynthDef. write the class file. More on this shortly. 25. Existing class files (e. An entire 808-drum machine. It may also be less efficient than an equivalent UGen. write the Help file. it forces you to think clearly about the inputs and outputs and how the UGen will be used in practice. But. of course. Pitch. Now let’s consider what is involved in creating a “real” UGen. . thus weeding out any conceptual errors. during development the Help file doesn’t need to be particularly beautiful. Third. This approach has definite limitations. A Help file is also a good reminder of what the UGen does — don’t underestimate the difficulties of returning to your own code. There is a “Documentation Style Guide” in the SC Help system which includes tips and recommendations for writing Help documentation. You don’t need to do this before starting on the C++ code.. Really — it’s a good idea to do this before you start coding. We now consider writing the class file and writing the plug-in code. Second. LPF. It is of course confined to processes that can be expressed as a combination of existing units — it can’t create new types of processing or new types of server behavior. because it creates a small subgraph of units that pass data to each other and must maintain their own internal states separately. but it’s a relatively simple step. months or years later. ` ` This is on the way toward becoming a useful reverb unit without having created a real plug-in at all. and trying to decipher your original intentions! The Help file will be an HTML file with the same name as the UGen. consider exactly what functionality you want to encapsulate into a single unit.g. or just the cymbal sound? Smaller components are typically better.

which processes the arguments and adds the UGen correctly to the SynthDef that is being built. with the following conditions: It must be a subclass of 8*HQ. These method names are referenced for rate checking during the SynthDef building process. Let’s look at a well-known example: 6LQ2VF8*HQ^  DU^ DUJIUHT SKDVH PXO DGG  AWKLVPXOWL1HZ DXGLR IUHTSKDVH.694 25.g. while the class file is for the language client. it’s the server that uses the plug-in code. and/or LU). The name of the class must match the name used in the plug-in code — the class name is used to tell the server which UGen to instantiate. This is so that methods defined in the 8*HQ class can be used when the language builds the SynthDef (synth graph definition). The class file does not have any direct connection with the C++ plug-in code — after all. The class methods must call the PXOWL1HZ method (defined in the main 8*HQ class). It must implement the appropriate class methods for the rates at which it can run (e.4 Dan Stowell Writing the Class File A class file for a UGen is much like any other SC class. NU.. DU.

PDGG PXODGG.

`  NU^ DUJIUHT SKDVH PXO DGG  AWKLVPXOWL1HZ FRQWURO IUHTSKDVH.

PDGG PXODGG.

” “VFDODU. which is 1 or more instances of the UGen we are interested in. The methods also call PDGG. Note that the PXO and DGG arguments are not being passed in to PXOWL1HZ. If any of these arguments are arrays.” or “GHPDQG. 6LQ2VF is a subclass of 8*HQ and implements 2 class methods. The first argument to PXOWL1HZ is a symbol to indicate the rate at which the particular UGen instance will be operating: this could be “DXGLR.” The remaining arguments are those that will actually be passed to the C++ plug-in — here IUHT and SKDVH. creating a separate unit to handle each channel. ` ` As you can see.” “FRQWURO. this is why the method is called PXOWL1HZ. In- . Both of these methods call PXOWL1HZ and return the result. which we’ll discuss shortly. PXOWL1HZ performs multichannel expansion. This means that the actual plug-in code for SinOsc will never be able to access them. Indeed.

695 25 Writing Unit Generator Plug-ins stead. no processing is really required. We’ll create a basic “flanger” which takes some input and then adds an effect controlled by rate and depth parameters: )ODQJHU8*HQ^  DU^ DUJLQUDWH GHSWK PXO DGG  AWKLVPXOWL1HZ DXGLR LQUDWHGHSWK. which is essentially a convenience for multiplication and addition of the unit’s output.) Let’s start to draft the class file for a UGen we can implement. they are often undocumented in Help files. these 2 arguments are often very useful and are supported by many UGens. (Due to their commonness. It is the convention to add PXO and DGG arguments to UGens as the final 2 arguments. the PDGG method performs some general optimizations (e.g. so the UGen is simply returned unaltered). this UGen makes use of the PDGG method. in the very common degenerate case of multiplying by 1 and adding 0.. As well as avoiding the programmer’s having to implement the multiplication and addition part of the process. as is done here.

PDGG PXODGG.

`  NU^ DUJLQUDWH GHSWK PXO DGG  AWKLVPXOWL1HZ FRQWURO LQUDWHGHSWK.

PDGG PXODGG.

4. an 6&:LQGRZ or a 7DVN). If you recompile. it is useful to add a bit of “sanity checking” to your UGen class to ensure that the user doesn’t try to connect things in a way that doesn’t make sense: for example. you’ll find that this is sufficient to allow you to use )ODQJHUDU or )ODQJHUNU in SynthDefs. The default method defined in 8*HQ simply passes through to FKHFN9DOLG.QSXWV method will be called. The 8*HQ class provides a FKHFN. ` ` Save this as Flanger. 25. plugging an audio-rate value into a scalar-rate input. because we haven’t created anything to tell the server how to produce the Flanger effect. When the SynthDef graph is built.sc in your extensions directory. each UGen’s FKHFN. which the SuperCollider language will happily compile — but of course those SynthDefs won’t run yet. say. .QSXWV method which you can override to perform any appropriate checks. which checks that each of the inputs is really something that can be plugged into a synth graph (and not some purely client-side object such as.1 Checking the Rates of Your Inputs Because SuperCollider supports different signal rates.QSXWV.

696 Dan Stowell The %XI:U UGen is an example which implements its own rate checking. Let’s look at what the class does: FKHFN.QSXWV^ LI UDWH  DXGLR DQG^LQSXWVDW .

UDWH  DXGLR `^  A SKDVHLQSXWLVQRWDXGLRUDWHLQSXWVDW .

LQSXWVDW .

 UDWH.

 `.

just like the first argument to PXOWL1HZ). each of which will be a UGen and thus will also have a UDWH variable. Observe the result of these checks: VERRW [ ^/3)DU :KLWH1RLVHNU. Therefore the class overrides the FKHFN. So the method compares the present unit’s rate against its first input’s rate.e. If you look at their class definition (or their superclass. the position at which data is written) must also be at audio rate — there’s no natural way to map control-rate index data to a buffer which is taking audio-rate data. filters such as /3) or +3). It simply returns a string if there’s a problem (returning anything other than nil is a sign of an error found while checking input).QSXWV ` If %XI:U is used to write audio-rate data to a buffer.QSXW. you’ll see that they call a convenience method for this common case called FKHFN6DPH5DWH$V)LUVW.. then it passes through to the default FKHFN9DOLG. Many UGens produce output at the same rate as their first input — for example.QSXWV method — if you implement your own method checking. don’t forget to pass through to this check. then the input specifying the phase (i. The UDWH variable is the rate of the unit under consideration (a symbol.QSXWV method to test explicitly for this. The LQSXWV variable is an array of the unit’s inputs. If there’s not a problem. in the case of /3) and +3) — an abstract class called )LOWHU). AWKLVFKHFN9DOLG.

`SOD\ V.

(UURU [ ^/3)DU :KLWH1RLVHDU.

`SOD\ V.

[IUHH [ ^/3)NU :KLWH1RLVHDU.2.

`SOD\ V.

(UURU [ ^/3)NU :KLWH1RLVHNU.

`SOD\ V.

.2. because it expects less input data than an audio-rate UGen — so if given audio-rate data. a UGen that expects audiorate data but is given only control-rate data may read garbage input from memory that it shouldn’t be reading. it simply ignores most of it. For example. a UGen that expects control-rate input is relatively safe. [IUHH What happens if you don’t add rate checking to your UGens? Often it makes little difference. But in the reverse case. but ignoring rate checking can sometimes lead to unusual errors that are hard to trace.

the “sc3-plug-ins” SourceForge project provides an SConstruct file purely for building UGens — you may find it easier to start from that as a template. including a UGEN_TEMPLATE_VCPROJ.QSXW approach. On Linux. Visual Studio project files are provided to compile plug-ins.” which has more details about the Xcode specifics. You can edit this file using a text editor to add your plug-in’s build instructions.5. Alternatively. of course. .5 Writing the C++ Code 25. UGen plug-ins are built just like any other C++ project. 25. . since the Flanger is a kind of filter.1 Build Environments: Xcode. You can. it calls the plug-in’s ORDG . It’s relatively painless to add a new “target” to this project in order to build your own plug-ins — this is the approach used in the SuperCollider Help document “Writing Unit Generators. the scons project file SConstruct is used to build SuperCollider as a whole. To make things easier for yourself as a developer. either directly or by modifying the class so that it subclasses )LOWHU rather than 8*HQ. scons .xcodeproj is used to build the core set of SuperCollider plug-ins. the Xcode project file Plugins. 25. In fact.5.vcprojtemplate file which you can use as a basis. you might think it sensible to use the FKHFN6DPH5DWH$V)LUVW.697 25 Writing Unit Generator Plug-ins Returning to the )ODQJHU example created earlier. you may wish to add rate checking to that class. you can use and adapt 1 of the project files which are distributed along with SuperCollider’s source code: On Mac. On Windows. use other build environments if you prefer.2 When Your Code Will Be Called The server (scsynth) will call your plug-in code at 4 distinct points: When scsynth boots.

. This is typically the function which does most of the interesting work in the UGen. Since it is called only once during a control period. scsynth calls each UGen’s calculation function in turn. this function must produce either a single control-rate value or a whole block’s worth of audiorate values during 1 call. which primarily declares which UGens the plug-in can provide. scsynth calls the UGen’s constructor function to perform the setting up of the UGen.) . When a UGen is instantiated (i. once for every control period. function. To produce sound. (Note: Demand UGens don’t quite fit this description and will be covered later. when a synth starts playing).e.

must be stored here.) The static .698 Dan Stowell When a synth is ended. Our constructor function. the LQFOXGH command calls the main header file for SuperCollider’s plug-in interface. In a given plug-in we are allowed to define 1 or more UGens. which needs to be remembered or passed from 1 audio block to the next. such as the rate at which the unit is running. This is sufficient to include enough SuperCollider infrastructure for most types of UGen. some UGens may need to perform some tidying up. Note that the struct inherits from the base struct 8QLW — this is necessary so that scsynth can correctly write information into the struct. 1 or more calculation (“next”) functions. This struct. such as freeing memory. We declare our UGen’s functions. If so. Each of these will have 1 constructor (“Ctor”) function. these UGens provide a destructor function which is called at this point.5. as described later. and optionally 1 destructor (“Dtor”) function.QWHUIDFH7DEOH pointer is a reference to a table of SuperCollider functions such as the ones used to register a new UGen. Here is what this code does: First. using the H[WHUQ& specifier so that the scsynth executable is able to reference the functions using C linkage. We define a data structure (a “struct”) which will hold any data we need to store during the operation of the UGen. more may be needed. SC_PlugIn. )ODQJHUB&WRU . 25. (For phase vocoder UGens.h.3 The C++ Code for a Basic UGen The code in figure 25.1 shows the key elements we need to include in our Flanger plug-in code.

For some of the other struct members. It must do the following 3 things: 1.1 . we wish to calculate the values based on an input to the UGen. In this case we initialize the GHOD\VL]H member to a value representing a 20-millisecond maximum delay. Initialize the Flanger struct’s member variables appropriately.. making use of the 6$03/(5$7( macro which the SuperCollider API provides to specify the sample rate for the UGen. We can do this using the . takes a pointer to a Flanger struct and must prepare the UGen for execution.

Here. we use .1 . macro. which grabs a single control-rate value from the specified input.

so we simply call 6(7&$/& )ODQJHUBQH[W. defined in the Flanger class file as “rate. this corresponds to the second input. The 6(7&$/& macro stores a reference to the function in our unit’s struct. In our example there’s only 1 choice. 2. — remembering that numbering starts at 0.” These macros (and others) will be discussed later. Tell scsynth what the calculation function will be for this instance of the UGen.

. It’s possible .

QWHUIDFH7DEOH IW WKHVWUXFWZLOOKROGGDWDZKLFKZHZDQWWRSDVVIURPRQHIXQFWLRQWRDQRWKHU HJIURPWKHFRQVWUXFWRUWRWKHFDOFIXQF RUIURPRQHFDOORIWKHFDOFIXQFWRWKHQH[W VWUXFW)ODQJHUSXEOLF8QLW^  IORDWUDWHGHOD\VL]HIZGKRSUHDGSRV  LQWZULWHSRV ` IXQFWLRQGHFODUDWLRQVH[SRVHGWR& H[WHUQ&^  YRLGORDG .QWHUIDFH7DEOH LQ7DEOH.699 25 Writing Unit Generator Plug-ins LQFOXGH6&B3OXJ.QK VWDWLF.

  YRLG)ODQJHUB&WRU )ODQJHU XQLW.

  YRLG)ODQJHUBQH[W )ODQJHU XQLWLQWLQ1XP6DPSOHV.

 ` YRLG)ODQJHUB&WRU )ODQJHU XQLW.

^   +HUHZHPXVWLQLWLDOLVHVWDWHYDULDEOHVLQWKH)ODQJHUVWUXFW  XQLW!GHOD\VL]H 6$03/(5$7( I)L[HGPVPD[GHOD\  7\SLFDOO\ZLWKUHIHUHQFHWRFRQWUROUDWHVFDODUUDWHLQSXWV  IORDWUDWH .1 .

  5DWKHUWKDQXVLQJUDWHGLUHFWO\ZH UHJRLQJWRFDOFXODWHWKHVL]HRI  MXPSVZHPXVWPDNHHDFKWLPHWRVFDQWKURXJKWKHGHOD\OLQHDWUDWH  IORDWGHOWD  XQLW!GHOD\VL]H UDWH.

6$03/(5$7(  XQLW!IZGKRS GHOWDI  XQLW!UDWH UDWH        ` .03257$177KLVWHOOVVFV\QWKWKHQDPHRIWKHFDOFXODWLRQIXQFWLRQ IRUWKLV8*HQ 6(7&$/& )ODQJHUBQH[W.

 6KRXOGDOVRFDOFVDPSOH VZRUWKRIRXWSXW² HQVXUHVHDFKXJHQ VSLSHVDUHSULPHG )ODQJHUBQH[W XQLW.

1 C++ code for a Flanger UGen. . but contains the key elements required for all UGens. This code doesn’t add any effect to the sound yet. Figure 25.

700 Dan Stowell YRLG)ODQJHUBQH[W )ODQJHU XQLWLQWLQ1XP6DPSOHV.

1 .^   IORDW LQ .

 IORDW RXW 287 .

1 .  IORDWGHSWK .

      IORDWUDWH IORDWIZGKRS IORDWUHDGSRV LQWZULWHSRV LQWGHOD\VL]H  IORDWYDOGHOD\HG   IRU LQWL LLQ1XP6DPSOHVL.

^  YDO LQ>L@     'RVRPHWKLQJWRWKHVLJQDOEHIRUHRXWSXWWLQJ  QRW\HWGRQH.

   ` RXW>L@ YDO   ` XQLW!ZULWHSRV ZULWHSRV XQLW!UHDGSRV UHDGSRV XQLW!UDWH XQLW!IZGKRS XQLW!UHDGSRV XQLW!ZULWHSRV XQLW!GHOD\VL]H YRLGORDG .QWHUIDFH7DEOH LQ7DEOH.

^  IW LQ7DEOH  ` 'HILQH6LPSOH8QLW )ODQJHU.

1 (continued) . Figure 25.

3. )ODQJHUBQH[W .701 25 Writing Unit Generator Plug-ins to define multiple calculation functions and allow the constructor to decide which one to use. The purpose of this is to “prime” the inputs and outputs of all the unit generators in the graph and to ensure that the constructors for UGens farther down the chain have their input values available so they can initialize correctly. This is covered later. Calculate one sample’s worth of output. typically by calling the unit’s calculation function and asking it to process 1 sample. Our calculation function.

more for audio-rate — typically 64). In this example it doesn’t actually alter the sound — we’ll get to that shortly — but it illustrates some important features of calculation functions.. should perform the main audio processing. The last thing in our C++ file is the ORDG . It takes 2 arguments passed in by the server: a pointer to the struct and an integer specifying how many values are to be processed (this will be 1 for control-rate.

We store the reference to the interface table which is passed in — note that although you don’t see any explicit references to IW elsewhere in the code. We must also declare to the server each of the UGens which our plug-in defines. function. that’s because they are hidden behind macros which make use of it to call functions in the server. called when the scsynth executable boots up. This is done using a macro 'HILQH6LPSOH8QLW )ODQJHU.

we would instead use 'HILQH'WRU8QLW )ODQJHU. It also tells the server that no destructor function is needed. which tells the server to register a UGen with the name Flanger and with a constructor function named Flanger_Ctor. If we did require a destructor..

which tells the server that we’ve also supplied a destructor function named Flanger_Dtor. the basic pattern for a typical calculation function is given. So what is happening inside our calculation function? Although in our example the input doesn’t actually get altered before being output.1 . You must name your constructor/destructor functions in this way. since the naming convention is hardcoded into the macros. We do the following: Create pointers to the input and output arrays which we will access: IORDW LQ  The macros ..

and 287 .

then LQ>@ will refer to the first incoming sample. LQ>@ to the next incoming sample. and so on. If the input is control-rate. LQ>@. We use the macro .1 . then there is only 1 incoming value. return appropriate pointers for the desired inputs/outputs — in this case the first input and the first output. If the input is audio-rate.

1 . again to grab a single control-rate value. here the “depth” input. Note that .

is actually a shortcut to the first value in the location referenced by .1 .

..1 .

1 . is exactly the same as .

>@.1 . .

IORDW RXW 287 .

..

Two important notes: If an input/output is control-rate and you mistakenly treat it as audio-rate. leading to undesired behavior. and producing an output value.QSXW approach is useful in this case. essentially this is just the classic C/C++ “gotcha” of accidentally treating an array as being bigger than it really is. You can see why the FKHFN6DPH5DWH$V)LUVW. then the input may be overwritten with output. but in this example we’re using only 1 full-rate input and producing a single output. since the C++ optimizer will typically cause the values to be loaded into registers. although it’s possible that they aren’t — some UGens can take audio-rate input and produce control-rate output. processing it. and this can cause bizarre problems and crashes. we assume that the input and output are of the same size. each time taking an input value. If you break this rule. This means that any of the output buffers may be the same as 1 of the input buffers. You must be careful. however. The server uses a “buffer coloring” algorithm to minimize use of buffers and to optimize cache performance. This allows for in-place operation. you will be reading/writing memory you should not be. If you can’t write the UGen efficiently without breaking this rule. then you can instruct the server not to alias the buffers by using the 'HILQH6LPSOH&DQW$OLDV8QLW . This can improve the efficiency of the unit. Next we loop over the number of input frames. not to write any output sample before you have read the corresponding input sample. and even produce multiple outputs. Note that in our example. We could take values from multiple inputs.702 Dan Stowell We copy some values from the UGen’s struct into local variables. This is why it is useful to make sure your SuperCollider class code includes the rate-checking code described earlier in this chapter. which is very efficient.

or 'HILQH'WRU&DQW$OLDV8QLW .

macros in the ORDG .

rather than the 'HILQH6LPSOH8QLW . function.

or 'HILQH'WRU8QLW .

having produced our output.) Finally. we need to store them back to the struct so the updated values are used next time. Here we store the UDWH value back to the struct — although we don’t modify it in this example. (The Help file on writing UGens provides an example in which this ordering is important. macros. The code in figure 25. you can now use the UGen in a synth graph: VERRW [ ^ YDUVRQGO\RXW VRQ 6DZDU >@. we will shortly change the code so that this may happen. With the class file in place and the plug-in compiled. we may have modified some of the variables we loaded from the struct.1 should compile correctly into a plug-in.

PHDQ RXW )ODQJHUDU VRQ.

 .

703 25 Writing Unit Generator Plug-ins RXWGXS  `SOD\ V.

 .

1 .4 Summary: The Three Main Rates of Data Output Our example has taken input in 3 different ways: Using . 25. But we can at least check that it runs correctly (outputting its input unmodified and undistorted) before we start to make things interesting.5. Remember that Flanger doesn’t currently add any effect to the sound.

1 . Using . Since this reads a value only once. in the constructor to take an input value and store it to the struct for later use. the input is being treated as a scalar-rate input.

This treats the input as control-rate.1 . in the calculation function to take a single input value. Using .

there is no danger in treating it as control-rate or scalar-rate. The end result is to ignore the “extra” data provided to your UGen. we need to free this memory when the UGen is freed. The result would be crude downsampling without low-pass filtering. in the calculation function to get a pointer to the whole array of inputs. as well as the code to allocate.2). This requires a UGen with a destructor. Note the change in the ORDG .5. If the data that one of your UGen’s inputs is fed is actually audio-rate. with the destructor added. 25. Typically the size of such an input array is accessed using the LQ1XP6DPSOHV argument. And.5 Allocating Memory and Using a Destructor Next we can develop our Flanger example so that it applies an effect to the sound. so you should instead use the macro )8//%8)/(1*7+ (see table 25. we need to allocate some memory and store a reference to that memory in the UGen’s data structure. We vary the amount of delay and mix the delayed sound with the input to produce the effect. free. but note that if you create a control-rate UGen with audio-rate inputs. To create a delay line. of course. Figure 25.2 shows the full code. a control-rate input can safely be treated as scalar-rate. we need a short delay line (around 20 milliseconds). In order to create a flanging effect. which may be undesirable but will not crash the server. then LQ1XP6DPSOHV will be wrong (it will be 1). and use the memory. This treats the input as audio-rate. Similarly.

function — we use 'HILQH'WRU 8QLW .

rather than 'HILQH6LPSOH8QLW .

(We’ve also added code to the calculation function which reads and writes to the delay line. creating the flanging effect.) ..

QWHUIDFH7DEOH IW WKHVWUXFWZLOOKROGGDWDZKLFKZHZDQWWRSDVVIURPRQHIXQFWLRQWRDQRWKHU HJIURPWKHFRQVWUXFWRUWRWKHFDOFIXQF RUIURPRQHFDOORIWKHFDOFIXQFWRWKHQH[W VWUXFW)ODQJHUSXEOLF8QLW^  IORDWUDWHGHOD\VL]HIZGKRSUHDGSRV  LQWZULWHSRV   DSRLQWHUWRWKHPHPRU\ZH OOXVHIRURXULQWHUQDOGHOD\  IORDW GHOD\OLQH ` IXQFWLRQGHFODUDWLRQVH[SRVHGWR& H[WHUQ&^  YRLGORDG .704 Dan Stowell LQFOXGH6&B3OXJ.QK VWDWLF.QWHUIDFH7DEOH LQ7DEOH.

  YRLG)ODQJHUB&WRU )ODQJHU XQLW.

  YRLG)ODQJHUBQH[W )ODQJHU XQLWLQWLQ1XP6DPSOHV.

  YRLG)ODQJHUB'WRU )ODQJHU XQLW.

 ` YRLG)ODQJHUB&WRU )ODQJHU XQLW.

1 .^            +HUHZHPXVWLQLWLDOLVHVWDWHYDULDEOHVLQWKH)ODQJHUVWUXFW XQLW!GHOD\VL]H 6$03/(5$7( I)L[HGPVPD[GHOD\ 7\SLFDOO\ZLWKUHIHUHQFHWRFRQWUROUDWHVFDODUUDWHLQSXWV IORDWUDWH .

 5DWKHUWKDQXVLQJUDWHGLUHFWO\ZH UHJRLQJWRFDOFXODWHWKHVL]HRI MXPSVZHPXVWPDNHHDFKWLPHWRVFDQWKURXJKWKHGHOD\OLQHDWUDWH IORDWGHOWD  XQLW!GHOD\VL]H UDWH.

6$03/(5$7( XQLW!IZGKRS GHOWDI XQLW!UDWH UDWH XQLW!ZULWHSRV  XQLW!UHDGSRV   $OORFDWHWKHGHOD\OLQH  XQLW!GHOD\OLQH  IORDW .

57$OORF XQLW!P:RUOGXQLW!GHOD\VL]H  VL]HRI IORDW.

.

  . .QLWLDOLVHLWWR]HURHV Figure 25.2 Completed C++ code for the Flanger UGen.

705 25 Writing Unit Generator Plug-ins  PHPVHW XQLW!GHOD\OLQHXQLW!GHOD\VL]H VL]HRI IORDW.

.

        ` .03257$177KLVWHOOVVFV\QWKWKHQDPHRIWKHFDOFXODWLRQIXQFWLRQ IRUWKLV8*HQ 6(7&$/& )ODQJHUBQH[W.

 6KRXOGDOVRFDOFVDPSOH VZRUWKRIRXWSXW² HQVXUHVHDFKXJHQ VSLSHVDUHSULPHG )ODQJHUBQH[W XQLW.

 YRLG)ODQJHUBQH[W )ODQJHU XQLWLQWLQ1XP6DPSOHV.

^   IORDW LQ .1 .

 IORDW RXW 287 .

1 .  IORDWGHSWK .

       IORDWUDWH XQLW!UDWH IORDWIZGKRS XQLW!IZGKRS IORDWUHDGSRV XQLW!UHDGSRV IORDW GHOD\OLQH XQLW!GHOD\OLQH LQWZULWHSRV XQLW!ZULWHSRV LQWGHOD\VL]H XQLW!GHOD\VL]H  IORDWYDOGHOD\HGFXUUDWH  FXUUDWH .1 .

         LI UDWH FXUUDWH.

^  UDWHLQSXWQHHGVXSGDWLQJ  UDWH FXUUDWH  IZGKRS  GHOD\VL]H UDWH .

6$03/(5$7(.

I `         IRU LQWL LLQ1XP6DPSOHVL.

^  YDO LQ>L@ :ULWHWRWKHGHOD\OLQH GHOD\OLQH>ZULWHSRV@ YDO LI ZULWHSRV GHOD\VL]H.

2 (continued) .  ZULWHSRV  Figure 25.

706 Dan Stowell                   5HDGIURPWKHGHOD\OLQH GHOD\HG GHOD\OLQH> LQW.

UHDGSRV@ UHDGSRV IZGKRS 8SGDWHSRVLWLRQ1%ZHPD\EHPRYLQJIRUZDUGVRUEDFNZDUGV  GHSHQGLQJRQLQSXW.

ZKLOH LQW.

UHDGSRV! GHOD\VL]H.

 UHDGSRV GHOD\VL]H ZKLOH LQW.

UHDGSRV.

 UHDGSRV GHOD\VL]H      ` 0L[GU\DQGZHWWRJHWKHUDQGRXWSXWWKHP RXW>L@ YDO GHOD\HG GHSWK.

     ` XQLW!UDWH UDWH XQLW!IZGKRS IZGKRS XQLW!ZULWHSRV ZULWHSRV XQLW!UHDGSRV UHDGSRV YRLG)ODQJHUB'WRU )ODQJHU XQLW.

^  57)UHH XQLW!P:RUOGXQLW!GHOD\OLQH.

 ` YRLGORDG .QWHUIDFH7DEOH LQ7DEOH.

^  IW LQ7DEOH  ` 'HILQH'WRU8QLW )ODQJHU.

 Figure 25.2 (continued) .

707 25 Writing Unit Generator Plug-ins Table 25.1 Memory Allocation and Freeing Typical C Allocation/Freeing In SuperCollider (using the real-time pool) YRLG SWU PDOORF QXPE\WHV.

IUHH SWU.

YRLG SWU 57$OORF XQLW!P:RUOGQXPE\WHV.

57)UHH XQLW!P:RUOGSWU.

15$7( .2. used in the constructor. to client-side processes).1. 25. This code. you may prefer to use a buffer allocated and then passed in from outside — this is described later.g. Memory allocated in this way is taken from the (limited) real-time pool and is not accessible outside the UGen (e. would choose between 2 calculation functions according to whether the first input was audio-rate or not: LI . This gives an opportunity to provide different functions optimized for different situations (e. Ordinary memory allocation and freeing can be a relatively expensive operation. If you require large amounts of memory or wish to access the data from the client. SuperCollider UGens allocate memory differently from most programs. as is done in figure 25..5..6 Providing More Than 1 Calculation Function Your UGen’s choice of calculation function is specified within the constructor rather than being fixed.g. and the analogous functions (the ones to avoid) are shown in the left-hand column. so SuperCollider provides a real-time pool of memory from which UGens can borrow chunks in an efficient manner. 1 for control-rate and 1 for audio-rate input) and to decide which to use. Often you will 57$OORF the memory during the constructor and 57)UHH it during the destructor. 57$OORF and 57)UHH can be called anywhere in your constructor/calculation/ destructor functions. The functions to use in a plug-in are in the right-hand column of table 25.

 FDOFB)XOO5DWH.

^ 6(7&$/& )ODQJHUBQH[WBD.

 `HOVH^ 6(7&$/& )ODQJHUBQH[WBN.

 ` You would then provide both a )ODQJHUBQH[WBD .

and a )ODQJHUBQH[WBN .

and so on.2). function. by testing whether %8)/(1*7+ is 1. . Similarly. you could specify different calculation functions for audio-rate versus control-rate output (e. although this is often catered for automatically when your calculation function uses the LQ1XP6DPSOHV argument to control the number of loops performed.g. see table 25..

. DetectSilence. including IORDW EXI'DWD.” as used in EnvGen.1(index) A float* pointer to input number index 287(index) A float* pointer to output number index .15$7((index) The rate of input index. A function which sets all the unit’s outputs to 0 inNumSamples) 3ULQW(fmt.708 Dan Stowell Table 25. looks this buffer up in the server. Note: for control-rate UGens this is not the full audio rate but audio rate/blocksize) 6$03/('85 Reciprocal of 6$03/(5$7( (seconds per sample) %8)/(1*7+ Equal to the block size if the unit is audio rate and to 1 if the unit is control rate %8)5$7( The control rate as a double %8)'85 The reciprocal of %8)5$7( *(7%8) Treats the UGen’s first input as a reference to a buffer.. numBytes) numBytes) . unit) Perform a “doneAction.1(index) A single (control-rate) value from input number index 287(index) A single (control-rate) value at output number index . numBytes) Allocate memory from the real-time pool— analogous to malloc(numBytes) 575HDOORF(world. Reallocate memory in the real-time pool— analogous to realloc(pointer. pointer. XLQW EXI)UDPHV for how many frames the buffer contains.2 Useful Macros for UGen Writers Macro Description . arguments are just like those for the C function printf 'RQH$FWLRQ(doneAction. an integer value corresponding to 1 of the following constants: FDOFB6FDODU5DWH (scalar-rate) FDOFB%XI5DWH (control-rate) FDOFB)XOO5DWH (audio-rate) FDOFB'HPDQG5DWH (demand-rate) 6(7&$/&(func) Set the calculation function to func 6$03/(5$7( The sample rate of the UGen as a double. which points to the data.) Print text to the SuperCollider post window. . XLQWEXI&KDQQHOV for the number of channels in the buffer &OHDU8QLW2XWSXWV(unit. and others 57$OORF(world. and provides variables for accessing it.

pointer) Free allocated memory back to the real-time pool— analogous to free(pointer) 6HQG7ULJJHU(node. value) Send a trigger from the node to clients.709 25 Writing Unit Generator Plug-ins Table 25. triggerID. with integer ID. triggered.2 (continued) Macro Description 57)UHH(world. and float value value )8//5$7( The full audio sample rate of the server (irrespective of the rate of the UGen) as a double )8//%8)/(1*7+ The integer number of samples in an audio-rate input (irrespective of the rate of the UGen) The unit’s calculation function can also be changed during execution — the 6(7&$/& .

macro can safely be called from a calculation function. not just from the constructor. Whenever you call 6(7&$/& .

this changes which function the server will call. The Help file on writing UGens shows more examples of 6(7&$/& . from the next control period onward..

1 . This means that our struct will need a member to store the previous value for checking. use this same convention..7 Trigger Inputs Many UGens make use of trigger inputs. then crosses to any positive value. the following sketch outlines how we handle the incoming data in our calculation function: ҽRDWWULJ .e. The convention here is that if the input is nonpositive (i. in use. If you wish to provide trigger inputs. a trigger has occurred. Assuming that our struct contains a float member SUHYWULJ.5. 25. The change from nonpositive to positive requires checking the trigger input’s value against its previous value. 0 or negative).

2UZKLFKHYHULQSXW\RXZLVK ҽRDWSUHYWULJ XQLW!SUHYWULJ LI SUHYWULJ  WULJ!.

but a similar approach is used for audio-rate triggering. too. Note that for the very first value in the block. For audio-rate triggering.^ GRVRPHWKLQJ ` XQLW!SUHYWULJ WULJ6WRUHFXUUHQWYDOXH³³QH[WWLPHLW OOEHWKH SUHYLRXVYDOXH The sketch is for a control-rate trigger input. . you need to compare each value in the input block against the value immediately previous. you need to compare against the last value from the previous block (which you must have stored).

found in TriggerUGens. You can call *(7B%8) near the top of your calculation function. The server creates an instance of the random number generator for UGens to access.8 Accessing a Buffer When a buffer is allocated and then passed in to a UGen.5. and then the data are available via a float pointer EXI'DWD along with 2 integers defining the size of the buffer.cpp in the main SC distribution. EXI&KDQQHOV and EXI)UDPHV. look at the source of the 7ULJ UGen.cpp in the main SC distribution. For examples which use this approach. bilinear. also available client-side). Note that the macro assumes the buffer index is the first input to the UGen (this is the case for most buffer-using UGens). The following excerpt shows how to generate random numbers for use in your code: 5*HQ UJHQ  XQLW!P3DUHQW!P5*HQ ҽRDWUҽ UJHQIUDQG . In practice this is most easily achieved by using a macro called *(7B%8).710 Dan Stowell For complete code examples. the UGen must look it up in the server’s list of buffers. 25. The randomness API is specified in SC_RGen. and quasi-Gaussian (such as VXPUDQG. 25.5.Q or 'LVN2XW UGens. The memory is managed externally by the buffer allocation/freeing server commands. In order to get a pointer to the correct chunk of memory (as well as the size of that chunk).9 Randomness The API provides a convenient interface for accessing good-quality pseudo-random numbers. defined in DiskIO_UGens. Your UGen does not need to free the memory associated with a buffer once it ends. exponential. look at the code for the 'LVN.h and provides functions for random numbers from standard types of distribution: uniform. the UGen receives the index number of that buffer as a float value.

$UDQGRPҽRDWXQLIRUPO\GLVWULEXWHGWR  LQWUYDO UJHQLUDQG .

$UDQGRPLQWHJHUXQLIRUPO\GLVWULEXWHG WRLQFOXVLYH ҽRDWUJDXV UJHQVXPUDQG .

There are 3 specific behaviors that might be appropriate if your UGen does reach a natural end: .10 When Your UGen Has No More to Do Many UGens carry on indefinitely.4XDVL*DXVVLDQOLPLWHGWRUDQJH“ 25. but often a UGen reaches the end of its useful “life” (e. it finishes outputting an envelope or playing a buffer).g..5.

2. set the flag as follows: XQLW!P'RQH WUXH This doesn’t affect how the server treats the UGen — the calculation function will still be called in future. Other UGens can monitor this and act in response to it (e. /LQHQ. You can implement this yourself simply by calling the 'RQH$FWLRQ .g.. 'XW\. )UHH6HOI:KHQ'RQH). 'RQH. and /LQH provide a “doneAction” feature which can perform actions such as freeing the node once the UGen has reached the end of its functionality. UGens such as (QY*HQ. See the Help files for examples of these UGens.711 25 Writing Unit Generator Plug-ins 1. Some UGens set a “done” flag to indicate that they’ve finished. If you wish your UGen to indicate that it has finished.

For example. if the doneAction is the sixth input to your UGen. you would call 'RQH$FWLRQ . You would typically allow the user to specify the doneAction as an input to the unit. which performs the desired action. macro.1 .

XQLW.

which sets its calculation function to a no-op 'HWHFW6LOHQFHBGRQH function at the point where it calls 'RQH$FWLRQ. for example. you can simply call the &OHDU8QLW2XWSXWV function as follows: &OHDU8QLW2XWSXWV XQLWLQ1XP6DPSOHV. many UGens stop calculating/outputting after they reach the point of calling this macro. though. If you wish to output zeroes from all outputs of your unit. the source code for 'HWHFW6LOHQFH. Not all GRQH$FWLRQV free the synth. See. so additional output is not always redundant. 3. Since this can perform behaviors such as freeing the node.

 Notice that this function has the same signature as a calculation function: as arguments it takes a pointer to the unit struct and an integer number of samples. You can take advantage of this similarity to provide an efficient way to stop producing output: 6(7&$/& &OHDU8QLW2XWSXWV.

Many of these are discussed in this chapter. Instead.h and SC_InterfaceTable. 25. but not all are covered explicitly.11 Summary of Useful Macros Table 25. Calling this would mean that your calculation function would not be called in future iterations.5. . Therefore this provides an irreversible but efficient way for your UGen to produce silent output for the remainder of the synth’s execution.2 summarized some of the most generally useful macros defined for use in your UGen code.h. &OHDU8QLW2XWSXWV would be called. The macros are defined in SC_Unit.

1 Multiple-Output UGens In the C++ code.6 Dan Stowell Specialized Types of UGen 25.6. The 287 . writing UGens which produce multiple outputs is very straightforward.712 25.

assign each one (287 . for a 3-output UGen. Thus. macro gets a pointer to the desired-numbered output.

. 287 .

. 287 .

then write output to these 3 pointers.) to a variable. and we need to modify this behavior. In the SuperCollider class code. the default is to assume a single output. Let’s look at the 3LWFK UGen to see how it’s done: 3LWFK0XOWL2XW8*HQ^  NU^DUJLQ LQLW)UHT PLQ)UHT PD[)UHT  H[HF)UHT PD[%LQV3HU2FWDYH PHGLDQ  DPS7KUHVKROG SHDN7KUHVKROG GRZQ6DPSOH  AWKLVPXOWL1HZ FRQWURO LQLQLW)UHTPLQ)UHTPD[)UHTH[HF)UHT  PD[%LQV3HU2FWDYHPHGLDQDPS7KUHVKROGSHDN7KUHVKROGGRZQ6DPSOH.

QSXWV AWKLVLQLW2XWSXWV UDWH.QSXWV LQSXWV WKH. ` LQLW^DUJWKH.

6. 3LWFK is a subclass of 0XOWL2XW8*HQ rather than of 8*HQ. The %XI:U and 5HFRUG%XI UGens are good examples of UGens that do exactly this: each UGen can . rather than having 1 unit per array element.e. Second. For 3LWFK.2 Passing Arrays into UGens 25. specified using the QXP&KDQQHOV argument.1 The class file As described earlier. 2).2. First. the first value from the list of inputs passed to init) and specifies that as the number of outputs. The init method for 3OD\%XI takes the QXP&KDQQHOV input (i. ` ` There are 2 differences from an ordinary UGen. but in some cases it might depend on other factors. 25. the number of outputs is fixed.. the LQLW function is overridden to say exactly how many outputs this UGen will provide (in this case.6. 0XOWL2XW8*HQ takes care of some of the changes needed to work with a UGen with multiple outputs. the PXOWL1HZ method automatically performs multichannel expansion if any of the inputs are arrays — yet in some cases we want a single unit to handle a whole array. 3OD\%XI is a good example of this: its number of outputs depends on the number of channels in the EXIIHU(s) it is expecting to play.

713 25 Writing Unit Generator Plug-ins take an array of inputs and write them to a multichannel buffer. Here’s how the class file handles this: 5HFRUG%XI8*HQ^  DU^DUJLQSXW$UUD\EXIQXP RIIVHW UHF/HYHO  SUH/HYHO UXQ ORRS WULJJHU   AWKLVPXOWL1HZ/LVW > DXGLR EXIQXPRIIVHWUHF/HYHOSUH/HYHO UXQORRSWULJJHU@LQSXW$UUD\DV$UUD\.

Our plug-in code will be able to detect how many inputs it receives in a given instance. However. the 3ROO class code must perform some other manipulations.2. converting a string of text into an array of ASCII characters and appending them to the end of its argument list. 3ROO shows how to do it using this array approach. Note that 5HFRUG%XI doesn’t know in advance what size the input array is going to be. so it is perhaps less clear as a code example than 5HFRUG%XI.6. Because of the array flattening that we perform. But if you are developing a UGen that needs to pass text data to the plug-in. in essence appears as a set of separate input arguments rather than a single array argument. for example. The 3ROO UGen uses a very similar procedure. which is the same except that all the arguments are a single array rather than a separated argument list. which will access the plug-in inputs according to their numerical position in the list. Why do we put LQSXW$UUD\ at the end of the argument list? Why not at the beginning. when concatenated onto the end of the argument list using the  array concatenation operator. this means that the 5HFRUG%XI C++ plug-in receives a variable number of inputs each time it is instantiated. we call PXOWL1HZ/LVW. The UHF/HYHO input.1 . whereas if we inserted LQSXW$UUD\ into the list before it. ` ` Instead of calling the 8*HQ method PXOWL1HZ. This means that the LQSXW$UUD\ argument (which could be either a single unit or an array). in parallel with how a user invokes the 5HFRUG%XI UGen? The reason is to make things simpler for the C++ code.2 The C++ code Ordinarily we access input data using the . 25. is always the third input. its position would depend on the size of LQSXW$UUD\.

1 . or .

QSXWV. But we need to know how many items to expect. The 8QLW struct can tell us how many inputs in total are being provided (the member XQLW!P1XP. since the array can be of variable size. There . Arrays are passed into the UGen as a separate numeric input for each array element. so we access these elements in exactly the same way. Look again at the 5HFRUG%XI class code given above. macro. specifying the number of the input we want to access.

QSXWV². Thus the number of channels in our input array is XQLW!P1XP. plus the array appended to the end.714 Dan Stowell are 7 “ordinary” inputs.

First. a demand-rate UGen can run at only 1 rate: the rate at which data are demanded of it. We use this information to iterate over the correct number of inputs and process each element.g.1 The class file Writing the class file for a demand-rate UGen is straightforward. rather than being invoked directly by the server. which during a particular control period could be more than once or not at all. the calculation function calls are actually passed up the chain of demand-rate generators.6.3. Look at the code for units such as 'VHULHV. QHZ.. with the constructor specifying the calculation function. However. This is because although some UGens may be able to run at multiple rates (e. They differ from other UGen class files in 2 ways: 1. audio rate or control rate). the calculation function behaves slightly differently.3. This means that you can’t make assumptions about regular timing. such as the assumptions made in an oscillator which increments its phase by a set amount each time it is called. or 'ZKLWH as examples. 2. 25.3 Demand-Rate UGens 25. Rather than using the .6. The first argument to PXOWL1HZ (or PXOWL1HZ/LVW) is GHPDQG . Second. rather than DU/ NU/ LU. 25..6.2 The C++ code The C++ code for a demand-rate UGen works as normal. it is not called regularly (once per control period) but only when demanded. They implement a single class method.1 . 'JHRP.

1 . or .

1387 . macros to access an input value (whose generation will have been coordinated by the server). we instead use the '(0$1'.

macro. which requests a new value directly from the unit farther up the chain.4 Phase Vocoder UGens Phase vocoder UGens operate on frequency-domain data stored in a buffer (produced by the ))7 UGen). “on demand. 25. demand-rate UGens are currently restricted to being single-output. They don’t operate at a special “rate” of their own: in reality they are control-rate UGens. its value . They produce and consume a control-rate signal which acts as a type of trigger: when an FFT frame is ready for processing.” Note: because of the method used to demand the data.6.

1 The class file As with demand-rate UGens. except that to access the frequency-domain data held in the external buffer.cpp should serve as a good example to base your own UGens on. and they specify their rate as “control” in the call to PXOWL1HZ. so it is sensible to stick with this convention. otherwise.4.e. but not both. one of which you use at the beginning of your calculation function to obtain the FFT data from the buffer.6. Your code should include the header file FFT_UGens. Two important macros are 39B*(7B%8) and 39B*(7B%8). but if the FFT chain has not “fired” in the current control block. 39B*(7B%8) will take the FFT chain indicated by the first input to the UGen and create a pointer to these data called EXI. phase vocoder UGens (PV UGens) can have only a single rate of operation: the rate at which FFT frames are arriving. Having acquired a pointer to the data. in fact your code will be executed only at the FFT frame rate. they do not allow the rest of the calculation function to proceed). there are certain macros and procedures to use. This has the important consequence that although your calculation function code will look “as if” it is called once per control block. you will of course wish to read/write that data. 25. The data in the buffer may be in .” then they access the buffer(s) and continue with the rest of the calculation function. then they output a value of –1 and return (i. PV UGens process data stored in buffers.4. The macros assume that the first input to the UGen is the one carrying the FFT chain where data will be read and then written. you must decide whether to process the complex-valued data as polar coordinates or Cartesian coordinates. Therefore.715 25 Writing Unit Generator Plug-ins is the appropriate buffer index. and the C++ API provides some useful macros to help with this. PV UGens implement only a single QHZ class method. 39B*(7B%8) is for use in UGens which process 2 FFT chains and write the result back out to the first chain: it takes the FFT chain indicated by the first and second inputs to the UGen and creates pointers to the data called EXI and EXI. It should be clear that you use 39B*(7B%8) or 39B*(7B%8). See the class files for 39B0DJ0XO and 39B%ULFN:DOO as examples of this.6. This signal is often referred to as the “chain” in SC documentation.2 The C++ code PV UGens are structured just like any other UGen.h. Before doing so.. These macros implement the special PV UGen behavior: if the FFT chain has “fired. 25. its value is –1. Any of the core UGens implemented in PV_UGens. which defines some PV-specific structs and macros.

To access the data as Cartesian values you use 6&&RPSOH[%XI S 7R&RPSOH[$S[ EXI.716 Dan Stowell either format (depending on what has happened to it so far).

 and to access the data as polar values you use 6&3RODU%XI S 7R3RODU$S[ EXI.

 These 2 data structures. but it’s what we’ll use here. The data in a Cartesian-type struct (an 6&&RPSOH[%XI) are of the form S!GF S!ELQ>@UHDO S!ELQ>@LPDJ S!ELQ>@UHDO S!ELQ>@LPDJ  S!ELQ>QXPELQV²@UHDO S!ELQ>QXPELQV²@LPDJ S!Q\T The data in a polar-type struct (an 6&3RODU%XI) is of the form S!GF S!ELQ>@PDJ S!ELQ>@SKDVH S!ELQ>@PDJ S!ELQ>@SKDVH  S!ELQ>QXPELQV²@PDJ S!ELQ>QXPELQV²@SKDVH S!Q\T .h. FFT data consist of a complex value for each frequency bin. and can therefore be neglected. But in the SuperCollider context the input is real-valued data. so these 2 bins can be represented by a single-magnitude value rather than a complex value. which is provided for us by 39B*(7B%8) or 39B*(7B%8). and a series of complex values for all the bins in between. and (b) phase is irrelevant for the DC and Nyquist frequency bins. The name S for the pointer is of course arbitrary. are declared in FFT_UGens. a single Nyquist value. and the 2 functions for obtaining them. The end result of this is that we obtain a data structure containing a single DC value. The number of bins in between is given by the value QXPELQV. which means that (a) the bins above the Nyquist frequency (which is half the sampling frequency) are a mirror image of the bins below. with the number of bins related to the number of samples in the input.

When compiling your PV UGen. ELQ>@ is actually the first nonDC bin — what would sometimes be referred to as the second bin.7 Practicalities 25. keep in mind that QXPELQV represents the number of bins not including the DC or Nyquist bins. simply read and write to the struct (which actually is directly in the external buffer). Similarly. To perform a phase vocoder manipulation. The simplest method is to add a line into your code which prints out values of variables — you can use the standard C++ SULQWI . 25.1 Debugging Standard C++ debugging procedures can be used when developing UGens. which provides the implementation of these frequency-domain data manipulations.cpp from the main SuperCollider source.717 25 Writing Unit Generator Plug-ins Note that the indexing is slightly strange: engineers commonly refer to the DC component as the “first” bin in the frequency-domain data. The buffer will then be passed down the chain to the next phase vocoder UGen. However in these structs.7. You don’t need to do anything extra to “output” the frequency-domain data. you will need to compile/link against SCComplex . because the DC component is represented differently.

The most common cause of crashes is introduced when using 57$OORF and 57)UHH — if you try to 57)UHH something that has not yet been 57$OORF’ed. then check that your code does not write data outside of the expected limits: make sure you 57$OORF the right amount of space for what you’re . In the latter case you need to ensure your debugger launches scsynth with the correct arguments (e. method. or otherwise is not a pointer to the real-time memory pool. you can launch the server process.. remember that the local server runs in a process different from the application. you may wish to look at your system’s crash log for scsynth. or you can launch just the server (scsynth) using the debugger. which in a UGen will print text to the post window. X). You can either launch the application using the debugger and booting the internal server. this can cause bad-access exceptions to appear in the crash log.g. which then runs as a local server. then attach a debugger such as gdb (the GNU debugger) or Xcode’s debugger (which is actually gdb with a graphical interface) to perform tasks such as pausing the process and inspecting values of variables. For more power. if you use the debugger to launch SuperCollider. When debugging a UGen that causes server crashes.app. If the crash log seems to reveal that your UGen is somehow causing crashes inside core UGens which normally behave perfectly. On Mac.

The difference between a UGen that takes 2.5% CPU may seem small.718 Dan Stowell doing (for example. floatingpoint division is typically much more expensive than multiplication. with arrays. However.2 Optimization Optimizing code is a vast topic and often depends on the specifics of the code in question.7. 25. especially since a user may wish to employ many instances of the UGen simultaneously. For example. rewrite this so that the reciprocal of that value is stored in the struct and you can perform a multiplication rather than a division. check exactly which indices your code attempts to access). but the first limits you to 40 simultaneous instances. Avoid calls to “expensive” procedures whenever possible. a 65% increase. use bit shifting (  Q) rather than the expensive math function (SRZ  Q. so if your unit must divide values by some constant value which is stored in your struct. we can suggest some optimization tips for writing SuperCollider UGens.5% and another that takes 1. while the second will allow up to 66. If you want to find an integer power of 2. Imagine doing your next live performance on a 4-year-old processor — that’s essentially the effect of the less efficient code. The efficiency/speed of execution is usually the number-one priority.

Precalculate and store such values wherever possible. often a filter UGen will take a user parameter (such as cutoff frequency) and use it to derive internal filter coefficients. since often UGens are used with fixed or rarely changing parameters.). to a certain combination of input rates.g. It can be helpful to allow any and all values to be updated at audio rate. In this . whether to do this at scalar/control/ audio rate. as demonstrated earlier). but if you find that a certain update procedure is expensive and won’t usually be required to run at audio rate. each appropriate to a certain context (e. Other expensive floating-point operations are square-root finding and trigonometric operations (VLQ. If you store the previous value of the user parameter and use this to check whether it has changed at all — updating the coefficients only upon a change — you can improve efficiency. can allow a lot of optimization.). FRV. and choosing the most appropriate. but the efficiency gains can be large. for reading a certain input or even performing a given calculation. etc. Creating multiple calculation functions. rather than calculating them afresh every time the calculation function is called. a purely controlrate calculation can avoid the looping required for audio-rate calculation and typically produces a much simpler calculation as a result. WDQ. One of the most important SuperCollider-specific choices is.. it may be preferable to update only once during a calculation function. As a typical example. For example. There is a maintenance overhead in providing these alternatives.

by precalculating some values which are going to be used in that big 100th call. To avoid this. “amortize” your unit’s effort by spreading the calculation out. For example. especially if referring to them multiple times. 'HILQH6LPSOH&DQW$OLDV8QLW is available as an alternative to 'HILQH6LPSOH8QLW in cases where your UGen must write output before it has read from the inputs. if possible. Avoid peaky CPU usage. use preprocessor instructions to choose between the Mac-specific code and ordinary C++ code: LI6&B'$5:.719 25 Writing Unit Generator Plug-ins tension between efficiency and code comprehensibility/reusability. but this can decrease cache performance. In your calculation function. A calculation function that does nothing for the first 99 times it’s called. then performs a mass of calculations on the 100th call.1 7KH0DFVSHFLҼFYHUVLRQRIWKHFRGH LQFOXGLQJHJY'63IXQFWLRQV. remember the considerations of platform independence. On Mac. If you make use of this. store values from your struct as well as input/output pointers/values as local variables. or other platform-specific libraries. As described earlier. Apple’s vDSP library can improve speed by vectorizing certain calculations. could cause audio dropouts if this spike is very large. you should remember the importance of adding comments to your code to clarify the flow and the design decisions you have made. Avoid 'HILQH6LPSOH&DQW$OLDV8QLW and 'HILQH'WRU&DQW$OLDV8QLW. This avoids the overhead of indirection and can be optimized (by the compiler) to use registers better.

“sc3-plug-ins.1 25. including the plug-in API.” exists as a repository for downloadable UGen plug-ins produced by various people. because you need to make sure that you update both branches in parallel. they must also be GPL-licensed. So if you wish to distribute your plug-ins to the world. (Note: you retain . HOVH 7KHJHQHULFYHUVLRQRIWKHFRGH HQGLI is a preprocessor value set to 1 when compiling SuperCollider on Mac (this is set in the Xcode project settings). You may wish to publish your work either there or separately. 6&B'$5:. Remember that SuperCollider is licensed under the well-known GPL (GNU Public License) open-source license. A SourceForge project.7.3 Distributing Your UGens Sharing UGens with others contributes to the SuperCollider community and is a very cool thing to do. Branching like this introduces a maintenance overhead.

. • 25. Whether you are tweaking 1 of SuperCollider’s core UGens or developing something very specialized. You do not have to sign away your copyright in order to GPL-license a piece of code. If you want to delve deeper. you’ll find the exchange of ideas with SuperCollider developers can be rewarding for your own projects as well as for others and can feed into the ongoing development of SuperCollider as a uniquely powerful and flexible synthesis system. a copy of the GPL license text. but it provides you with the core of what all UGen programmers need to know. and the source code for existing UGens provides a wealth of useful code examples. • If your plug-in makes use of third-party libraries. The open-source nature of SuperCollider makes for a vibrant online developer community. you will find the online community to be a valuable resource for answers to questions not covered here.720 Dan Stowell copyright in any code you have written.) Practically. See the GNU GPL Web site for further discussion of what this means. those libraries must be available under a “GPL-compatible” copyright license. this has a couple of implications: You should include a copyright notice.8 Conclusion This chapter doesn’t offer an exhaustive list of all that’s possible. and the source code with your distributed plug-in.

26 Inside scsynth Ross Bencina This chapter explores the implementation internals of scsynth. As always. and function names used in this chapter match those in the scsynth source code. as I believe scsynth is fundamentally object-oriented. However. the source code is the definitive reference and provides many interesting details which space limitations didn’t allow to be included here. if not in an idiomatically C++ way. However. the information presented here is equally relevant to understanding scsynth’s non-real-time mode.” “The client” usually refers to sclang or any other program sending OSC commands to the server. In this chapter sometimes we’ll simply refer to scsynth as “the server. This chapter is intended to be useful to people who are interested in modifying or maintaining the scsynth source code and also to those who are interested in learning about the structure and implementation details of one of the great milestones in computer music software. All other references to names appear here as they do in the source code. structure. In many cases structs from the source code appear as classes in the diagrams. Now that formalities are completed. Where appropriate. Sometimes you may find that the source file. I have resisted the urge to translate any other constructs (such as the psuedo member functions mentioned below). you should have improved your understanding of how scsynth does what it does and also have gained some insight into why it is written the way it is. I have taken the liberty to interpret inheritance where a base struct is included as the first member of a derived struct. Although the text focuses on the server’s real-time operating mode. Also note that I have chosen to emphasize an object-oriented interpretation of scsynth using UML diagrams to illuminate the code structure. the server process of SuperCollider 3. By the time you’ve finished this chapter. I have omitted such prefixes from class and function names for consistency. which is written in C++. Following that. in the next section we set out on our journey through the scsynth implementation with a discussion of scsynth’s coding style. at the time of writing there was some inconsistency in class and structure naming. the class name. Wherever possible. we consider the structure of the code which implements what I call the . or both may have an SC_ prefix. the data.

Groups. These are declared with names of the form 6WUXFW7\SHB0HPEHU)XQFWLRQ1DPH 6WUXFW7\SH V>@. The final section briefly highlights some of the fine-grained details which make scsynth one of the most efficient software synthesizers on the planet. Functions which in idiomatic C++ might be considered member functions are typically global functions in scsynth. and their supporting infrastructure. especially those which are accessible to unit plug-ins. GraphDefs. interthread communications using queues. and how scsynth fulfills real-time performance constraints while executing all of the dynamic behavior offered by the domain model. Graphs.722 Ross Bencina scsynth domain model: Nodes. but for the most part uses a “C++ as a better C” coding style. Most data structures are declared as plain old C structs. I hope you get as much out of reading this chapter as I did in writing it! 26. we consider threading. We then go on to consider how the domain model implementation communicates with the outside world. scsynth is a fantastically elegant and interesting piece of software.1 Some Notes on scsynth Coding Style scsynth is coded in C++.

. Memory allocation is performed with custom allocators or with PDOORF . where the first parameter is a pointer to the struct being operated on (the “this” pointer in a C++ class).

. IUHH .

There is very little explicit encapsulation of data using getter/setter methods. as will be seen later.. which makes dynamically linking with plug-ins using C++ interfaces compilerversion-specific. The use of structs instead of C++ classes makes it less complicated to place objects into raw memory. The avoidance of C++ constructs also has the benefit of making all code operations visible. . Finally. A number of cases of what can be considered inheritance are implemented by placing an instance of the base class (or struct) as the first member of the derived struct. in turn making it easier to understand and predict the performance and real-time behavior of the code. and friends. Probably the most significant is the lack of an Application Binary Interface (ABI) for C++. Reusing a small number of data structures for many purposes eases the burden on memory allocation by ensuring that dynamic objects belong to only a small number of size classes. Function pointers are often used instead of virtual functions. There are a number of pragmatic reasons to adopt this style of coding. The separation of data from operations and the explicit representation of operations as data-using function pointers promotes a style of programming in which types are composed by parameterizing structs by function pointers and auxilliary data. being able to switch function pointers at runtime is a very powerful idiom which enables numerous optimizations.

:RUOG is the top-level class which (with the exception of a few global objects) aggregates and manages the run-time data in the server. The model is presented without concern for how client communication is managed or how the system is executed within real-time constraints. 2000). Interested readers are advised to consult the “ServerArchitecture” section of the Help files for further information about the roles of these classes and the exact operations which can be performed by them.1 shows an implementation-level view of the significant domain entities in scsynth.2 26 Inside scsynths The scsynth Domain Model At the heart of scsynth is a powerful yet simple domain model which manages dynamic allocation and evaluation of unit generator graphs in real time. In this section we explain the main behaviors and relationships between entities in the domain model. These concerns are addressed in later sections. Figure 26. SC users will recognize the concepts modeled by many of these classes. It is created by :RUOGB1HZ . Graphs can be grouped into arbitrary trees whose execution and evaluation order can be dynamically modified (McCartney. Each class shown on the diagram is a C++ class or struct in the scsynth source code.723 26.

when scsynth starts up. An instance of :RUOG2SWLRQV is passed to :RUOGB1HZ .

It stores the configuration parameters. each of which provides its own 1RGH&DOF)XQF function pointer. readers may recognize this as the Composite design pattern (Gamma et al.. The *UDSK type implements the SuperCollider concept of a Synth.1). 1995). or changing its location in the tree). *UDSK is so named because it executes an optimized graph of UGens. which is called by the server to evaluate the Node at the current time step. It can be likened to a voice in a synthesizer or an “instrument” in a Music N-type audio synthesis language such as Csound. which are usually passed to scsynth on the command line. 1RGHP. arbitrary trees may be constructed containing any combination of *URXS and *UDSK instances.' is an integer used by clients to identify specific Nodes in server commands (such as suspending or terminating the Node. There are 2 subtypes of 1RGH: *UDSK and *URXS. It does this by evaluating a tree of dynamically allocated 1RGH instances (near middle-left of figure 26. *URXS is simply a container for a linked list of 1RGH instances.. scsynth’s main task is to synthesize and process sound. and since *URXS is itself a type of 1RGH. The standard 1RGH&DOF)XQF for a Group (*URXSB&DOF .

Although most code deals with Nodes polymorphically. the 1RGHP. in 6&B*URXSFSS) simply iterates through the Group’s contained Nodes. calling each Node’s 1RGH&DOF)XQF in turn. which switches NodeCalcFuncs. a 1RGH&DOF)XQF which does .V*URXS field supports discriminating between Nodes of type *UDSK and of *URXS at runtime. Any node can be temporarily disabled using the QBUXQ server command. When a Node is switched off.

.1 Class diagram of significant domain entities.724 Ross Bencina Figure 26.

Units are efficiently allocated from the Graph’s memory block and evaluated by iterating through a linear array containing pointers to all of the Graph’s Units. Graphs are instantiated using a *UDSK'HI (Graph Definition). The *UDSK'HI type implements the SuperCollider concept of a SynthDef. Unit initialization parameters. and optimized in-memory information used to efficiently instantiate and evaluate Graphs. When a new GraphDef is loaded into the server. and information about the connections between Units. Disabling a Group disables the whole tree under that Group. most of the work is done in *UDSK'HIB5HDG . filtering. which affords the same kind of flexibility as 1RGH&DOF)XQF described above.725 26 Inside scsynths nothing is substituted for the usual one. *UDSK'HI instances store data such as memory allocation size for *UDSK instances. many Units implement a form of self-modifying code by switching their UnitCalcFuncs on the fly to execute different code paths. A *UDSK'HI includes both data for passive representation (used on disk and as communicated from clients such as sclang). depending on their state. Each 8QLW instance provides a 8QLW&DOF)XQF function pointer to compute samples. A *UDSK is an aggregate of interconnected 8QLW subclasses (also known as Unit Generators or UGens). 8QLW instances are responsible for performing primitive audio DSP operations such as mixing. which defines the structure of a class of Graphs. Each *UDSK instance is carved out of a single memory block to minimize the number of expensive calls to the memory allocator. and oscillator signal generation. For example.

. Aside from allocating and initializing memory and wiring in pointers. one of the main tasks *UDSK'HIB5HDG . which converts the stored representation to the run-time representation.

manipulation. including the buses used to hold control and audio input and output signals (e. The stored GraphDef representation specifies an interconnected graph of named 8QLW instances with generalized information about input and output routing. This information is loaded into an in-memory array of 8QLW6SHF instances where each Unit name is resolved to a pointer to a 8QLW'HI (see below).g. for example. This interconnection graph is traversed by a graph-coloring algorithm to compute an allocation of inter-Unit memory buffers. and evaluation of the tree of Nodes. :RUOG is responsible for managing the instantiation. to hold sound data loaded from disk.QSXW6SHF and 2XWSXW6SHF. ensuring that the minimum number of these buffers is used when evaluating the Graph. :RUOG also manages much of the server’s global state. scsynth’s tree of Nodes is rooted at a Group referenced by :RUOGP7RS*URXS. Note that the order of Unit evaluation defined by a GraphDef is not modified by scsynth.. performs is to determine which inter-Unit memory buffers will be used to pass data between Units during Graph evaluation. An instance of :RUOG is accessible to 8QLW plug-ins via 8QLWP:RUOG . and the Unit interconnection graph is represented by instances of . :RUOGP$XGLR%XV) and a table of 6QG%XI instances (aka Buffers) used.

QWHUIDFH7DEOH.726 Ross Bencina and provides :RUOGIW. an instance of . calling its ORDG .” When the server starts. 8QLW subclasses provide all of the signal-processing functionality of scsynth. which is a table of function pointers which Units can invoke to perform operations on the World. it scans the nominated plug-in directories and loads each plug-in. An example of Units using World state is the .Q and 2XW units which directly access :RUOGP$XGLR%XV to move audio data between Graphs and the global audio buses. They are defined in dynamically loaded executable “plug-ins.

function. Each call to I'HILQH8QLW . this registers all available Units in the plug-in with the World via the .QWHUIDFH7DEOHI'HILQH8QLW function pointer.

such as 'HILQH6LPSOH8QLW .QWHUIDFH7DEOHK. results in a new 8QLW'HI being created and registered with the global J8QLW'HI/LE hash table. although this process is usually simplified by calling the macros defined in 6&B.

and 'HILQH'WRU8QLW .

3. it is important that the time taken to compute each block is bounded and as close to constant as possible. which is used when a request to instantiate a new Graph is received. 26. not to the execution of real-time unsafe operations. We begin by considering what “real-time requirements” means in the context of scsynth and then explore how these requirements are met.3 Real-Time Implementation Structure We now turn our attention to the context in which the server is executed. computing complex synthesized audio does not come for free and necessarily takes time. Such unsafe operations include . which contains the memory used to pass data between Units during Graph evaluation. Any delay in providing audio data to the OS will almost certainly result in an audible glitch. memory allocation. 26. +LGGHQ:RUOGP*UDSK'HI/LE. scsynth is a real-time system. a hash table providing fast lookup of Nodes by integer ID. Of significance here are +LGGHQ:RUOGP1RGH/LE. and +LGGHQ:RUOGP:LUH%XI6SDFH. This includes considerations of threading. These blocks are relatively small (on the order of 2 milliseconds for current generation systems). and hence tolerances can be quite tight. and interthread communications. Some server data (more of which we will see later) is kept away from Unit plug-ins in an instance of +LGGHQ:RUOG. In general. the time taken to compute a block of audio must be less than the time it takes to play it. Of course. and the implementation is significantly influenced by real-time requirements. so that exceeding timing constraints occurs only due to the complexity or quantity of concurrently active Graphs.1 Real-Time Requirements scsynth’s primary responsibility is to compute blocks of audio data in a timely manner in response to requests from the OS audio service. a hash table of all loaded GraphDefs.. Nonetheless.

since it defines the pervasive mechanism for synchronization and communication between non-real-time threads and the real-time context which computes audio samples. When a non-realtime thread needs to perform an operation in the real-time context. you may wonder how scsynth can work at all in real time. allocate large blocks of memory. if code in the . Exhaustion of such data structures typically results in scsynth operations failing.3. such as attempting to lock a mutex or wait on a file handle. such as calling a system-level memory allocator or writing to a network socket. precomputing a lookup table or zeroing a large memory block at Unit startup) • Operations which block or otherwise cause a thread context switch. In general. and all will be revealed.2 Real-Time Messaging and Threading Implementation SuperCollider carefully avoids performing operations which may violate real-time constraints by using a combination of the following techniques: Communication to and from the real-time context is mediated by lock-free First In First Out (FIFO) queues containing executable messages • Use of a fixed-pool memory allocator which is accessed only from the real-time context • Non-real-time safe operations (when they must be performed at all) are deferred and executed asynchronously in a separate “non-real-time” thread • Algorithms which could introduce unpredictable or transient high computational load are generally avoided • Use of user-configurable nonresizable data structures. no real-time unsafe operation may be performed in the execution context which computes audio data in real time (usually a thread managed by the OS audio service). Put simply. but also operations which may block due to unknown implementation strategies. • The third category includes not only explicit blocking operations. 26.727 26 Inside scsynths Algorithms with high or unpredictable computational complexity (for example. amortized time algorithms with poor worst-case performance) • Algorithms which intermittently perform large computations (for example. and communicate with clients via network sockets. since there is no way to know whether it will acquire a lock or otherwise block the process. Conversely. • The first point is possibly the most important to grasp. any system call should be considered real-time unsafe. Considering the above constraints alongside the dynamic behavior implied by the domain model described in the previous section and the fact that scsynth can read and write sound files on disk. Read on. it enqueues a message which is later performed in the real-time context.

).2 shows another view of the scsynth implementation. For clarity. Figure 26. note that the :ULWH . and half arrows indicate the flow of asynchronous messages across queues. only a few key classes from the domain model have been retained (shaded gray). this time focusing on the classes which support the real-time operation of the server. and the black circle indicates a condition variable. etc. Cylinders indicate FIFO message queue objects. The diagram can be interpreted as follows: thick rectangles indicate execution contexts. it sends the message to a non-real-time thread for execution. Full arrows indicate synchronous function calls (invocation of queue-member functions). The padlock indicates a lock (mutex). PortAudio for Windows. but for now. We will revisit this topic on a number of occasions throughout the remainder of the chapter.3 illustrates the run-time thread structure and the dynamic communication pathways between threads via lock-free FIFO message queues.728 Ross Bencina real-time context needs to execute a real-time unsafe operation. Figure 26. Note that $XGLR'ULYHU is a base class: in the implementation different subclasses of $XGLR'ULYHU are used depending on the target OS (CoreAudio for Mac OS X. The FIFO message queue mechanism will be discussed in more detail later in the chapter. which are either threads or callbacks from the operating system.

3HUIRUP . method enqueues a message.

executes message-specific behavior for each pending message. and )UHH .

The :ULWH . cleans up after messages which have been performed.

3HUIRUP ..

and )UHH ..

2 and 26. These listening threads dynamically allocate 26&B3DFNHWV and post them to “The Engine. the dynamic behavior of the server can be summarized as follows: 1. Referring to figures 26.3.” using the 3URFHVV26&3DFNHW . FIFO operations can be safely invoked by separate reader and writer threads without the use of locks. One or more threads listen to network sockets to receive incoming OSC messages which contain commands for the server to process.

which results in 3HUIRUPB7R(QJLQHB0VJ . function.

using )UHH26&3DFNHW . (a )LIR0VJ)XQF) being posted to the P2VF3DFNHWV7R(QJLQH queue. 26&B3DFNHW instances are later freed.

(a )LIR)UHH)XQF) by way of 0VJ)LIR)UHH .

“The Synthesis Engine. via a mechanism which is described in more detail later.” or “Engine” for short (also sometimes referred to here as “the real-time context”). is usually a callback function implemented by a concrete $XGLR'ULYHU which is periodically called by the OS audio service to process and generate audio. 2. The main steps relevant here are that the Engine calls 3HUIRUP ..

which execute the P3HUIRUP)XQF of any messages enqueued from other threads. instantiate . Messages in P2VF3DFNHWV7R(QJLQH carry 26&B3DFNHW instances which are interpreted to manipulate the Node tree. on the P2VF3DFNHWV7R(QJLQH and P7R(QJLQH queues.

729 26 Inside scsynths Figure 26. .2 Real-time threading and messaging implementation structure.

730 Ross Bencina Figure 26.3 Real-time thread and queue instances and asynchronous message channels. .

Whenever the Engine wants to perform a non-real-time safe operation.731 26 Inside scsynths new Graphs. Results of such operations (if any) will be returned via the P7R(QJLQH queue. it calls 6LJQDO . After processing messages from P2VF3DFNHWV7R(QJLQH. the Engine performs its audio duties by arranging for real-time audio data to be copied between OS buffers and P:RUOG!P$XGLR%XV and evaluating the 1RGH tree via P:RUOG!P7RS*URXS. P7R(QJLQH. When the Engine has completed filling the OS audio output buffers. and so on. it encodes the operation in a )LIR0HVVDJH instance and posts it to the nonreal-time thread for execution via the P)URP(QJLQH queue. and any previously scheduled OSC messages in P6FKHGXOHU.

Before the server starts servicing OS audio requests. When the non-real-time thread wakes up. on P$XGLR6\QF and returns to the OS. it creates a thread for executing real-time unsafe operations (the non-real-time or NRT thread). This thread waits on P$XGLR6\QF until it is signaled by the Engine. 3. it calls )UHH .

and 3HUIRUP .

P1RGH(QGV. on the P)URP(QJLQH queue to perform any non-real-time safe operations which the server has posted. then processes the P7ULJJHUV. Performing the enqueued notification messages results in OSC messages being sent to clients referenced by 5HSO\$GGUHVV. These queues contain notifications of server events. and P'HOHWH*UDSK'HIV queues. After calling 3HUIRUP .

Memory allocated with an $OORF3RRO must of course also be freed . the non-real-time thread returns to waiting on P$XGLR6\QF until it is next wakened by the Engine. This makes it possible for the server to perform many dynamic operations in the real-time thread without needing to defer to an NRT thread to allocate memory.1 Real-time memory pool allocator Memory allocations performed in the real-time context.2. on all queues. preallocated chunk of system memory. A number of these are discussed in the sections which follow. This is acceptable since the Engine assumes non-real-time operations will take as long as necessary. such as allocating memory for new *UDSK instances. $OORF3RRO is a reimplementation of Doug Lea’s fast general-purpose memory allocator algorithm (Lea. or it may not process the queues on every Engine cycle if it is occupied with time-consuming operations. However. 2000). The implementation allocates memory to clients from a large. are made using the $OORF3RRO class. The description above has painted the broad strokes of the server’s real-time behavior. it doesn’t need to use locks or other mechansims to protect its state from concurrent access and hence is real-time safe. Because $OORF3RRO is invoked only by code running in the real-time context. large allocations and other memory operations which are not time-critical are performed outside the real-time context.3. 26. it may never sleep. Zooming in to a finer level of detail reveals many interesting mechanisms which are worth the effort to explore. That said. Note that P$XGLR6\QF is used to ensure that the NRT thread will always wake up and process Engine requests in a timely manner.

and in the same execution context. )LIR0VJ instances posted by the Engine to the NRT thread with a payload allocated by $OORF3RRO must ensure that the payload is always freed into $OORF3RRO in the real-time execution context. This can be achieved using 0VJ)LIR)UHH . which requires some care to be taken. For example.732 Ross Bencina into the same $OORF3RRO.

W\SHGHIYRLG )LIR0VJ)XQF. data are read at the read pointer and the read pointer is advanced. 25. let’s consider the basic mechanism.. one for performing the operation and another for cleaning up. In our case the Command is a struct containing data and a pair of function pointers. This lock-free property makes the FIFO queue ideal for implementing realtime interthread communications in scsynth. But for now.. Figure 26. We will see later that scsynth also uses a variant of this scheme in which the Command is a C++ class with virtual functions for performing an operation in multiple stages.2. which involves posting )LIR0VJ instances to a queue of type 0VJ)LIR.2 FIFO queue message passing As already mentioned. and P)URP(QJLQH queues carry )LIR0VJ objects. possibly in a different thread. and then pass it off to some other part of the system for execution. The basic idea is to encode an operation to be performed as a class or struct. scsynth uses FIFO queues for communicating between threads. The code below shows the )LIR0VJ)XQF type and the key fields of )LIR0VJ. The basic concept of a FIFO queue is that you push items on one end of the queue and pop them off the other end later. If there’s guaranteed to be only 1 reading thread and 1 writing thread. P7R(QJLQH.2 shows that P2VF3DFNHWV7R(QJLQH. which is described in the next section. The queues which we are most concerned with here carry a payload of message objects between threads. which is then advanced.3. and you’re careful about how the pointers are updated (and take care of atomicity and memory ordering issues) then it’s possible to implement a thread-safe FIFO queue without needing to use any locks. This is an instance of the relatively well known Command design pattern (Gamma et al. when the reader detects that the queue is not empty. 1995). A fixedsize queue can be implemented as a circular buffer (also known as a ring buffer) with a read pointer and a write pointer: new data are placed in the queue at the write pointer.

VWUXFW)LIR0VJ .

 VWUXFW)LIR0VJ^  )LIR0VJ)XQFP3HUIRUP)XQF )LIR0VJ)XQFP)UHH)XQF YRLG P'DWD  ` .

the sender initializes a )LIR0VJ instance and passes it to 0VJ)LIR:ULWH .733 26 Inside scsynths To enqueue a message.

When the receiver calls 0VJ)LIR3HUIRUP . Each FifoMsg contains the function pointer members P3HUIRUP )XQF and P)UHH)XQF..

When 0VJ)LIR)UHH .. 0VJ)LIR also maintains an additional internal pointer which keeps track of which messages have been performed by the receiver. the P3HUIRUP)XQF of each enqueued message is called with a pointer to the message as a parameter.

2. however. a number of operations need to perform a sequence of steps alternating between the real-time context and the NRT thread. In a moment we will see how this mechanism is used to free SequencedCommand objects allocated in the real-time context. since 0VJ)LIR and 0VJ)LIR1R)UHH are templates parameterized by message type.3 SequencedCommand Unlike )LIR0VJ. These queues carry specialized notification messages. it was probably considered more efficient to create separate specialized queues using message types large enough to hold all of the necessary data rather than invoking the allocator for each request. the P)UHH)XQF is invoked on each message whose P3HUIRUP)XQF has already completed. not only for transporting OSC message packets to the real-time engine but also for arranging for the execution of real-time unsafe operations in the NRT thread. which just stores two C function pointers. Many server operations are implemented by the FifoMsgFuncs defined in 6&B0LVF&PGVFSS. Stage 1 and 3 execute in the real-time context. P1RGH(QGV. the basic )LIR0VJ mechanism is extended using the 6HTXHQFHG&RPPDQG class. and P'HOHWH*UDSK'HIV. 26. The 'HOHWH . 6HTXHQFHG&RPPDQG is a C++ abstract base class with virtual functions for executing up to 4 stages of a process. The )LIR0VJ mechanism is used extensively in scsynth. is called by the sending execution context. For this. such as P7ULJJHUV. The functionality of these queues could have been implemented by dynamically allocating payload data and sending it using )LIR0VJ instances. while stages 2 and 4 execute in the NRT context.3. However. A separate 0VJ)LIR1R)UHH class is provided for those FIFOs which don’t require this freeing mechanism.

1 for a list of SequencedCommands defined at the time of writing. SequencedCommands are used for operations which need to perform some of their processing in the NRT context. function is always called in the RT context. even while unit generators are using them. or contain . which reads: “Buffers are stored in a single global array indexed by integers beginning with zero. (See table 26. Buffers may be safely allocated. all 6HTXHQFHG&RPPDQG subclasses were defined in 6&B6HTXHQFHG&RPPDQG FSS. loaded and freed while synthesis is running. They are mostly concerned with the manipulation of SndBufs and GraphDefs.” Given that a SndBuf’s sample storage can be quite large. At the time of writing.) To provide a concrete example of the SequencedCommand mechanism. we turn to the Help file for Buffer (aka 6QG%XI). potentially providing a fifth stage of execution.

NotifyCmd. SendReplyCmd. We now describe how the SequencedCommand mechanism is used to implement this behavior. SendFailureCmd. BufAllocReadCmd. Each is always in a consistent state but is accessed or modified only in its own context: P6QG%XIV in the RT context via :RUOGB*HW%XI . we draw a distinction between instance data of 6QG%XI and the sample data array pointed to by 6QG%XIGDWD. To begin. it is clear that it needs to be allocated and initialized in the NRT thread.1 Subclasses of 6HTXHQFHG&RPPDQG Defined in SC_SequencedCommand. The actual sample data are stored in a dynamically allocated floating-point array pointed to by 6QG%XIGDWD. In contrast to the client-oriented worldview presented in the Help file. BufAllocCmd. AsyncPlugInCmd sample data read from disk.734 Ross Bencina Table 26. BufFreeCmd.cpp Buffer Commands BufGenCmd. BufCloseCmd. BufWriteCmd GraphDef Commands LoadSynthDefCmd. RecvSynthDefCmd. AudioStatusCmd. :RUOG actually maintains 2 separate arrays of 6QG%XI instances: P6QG%XIV and P6QG%XIV1RQ 5HDO7LPH0LUURU. channel count. BufReadCmd. SyncCmd. it is important to note that the 6QG%XI class is a relatively lightweight data structure which mainly contains metadata such as the sample rate. SC_BufReadCommand. LoadSynthDefDirCmd Miscellaneous AudioQuitCmd. BufZeroCmd. In the explanation which follows. and number of frames of the stored audio data.

and P6QG%XIV1RQ 5HDO7LPH0LUURU in the NRT thread via :RUOGB*HW157%XI .

. On each iteration the engine performs messages in P7R(QJLQH and then evaluates the 1RGH tree to generate sound. Any changes to P6QG%XIV made when calling P7R(QJLQH!3HUIRUP .

The details of the individual steps are described below. a subclass of 6HTXHQFHG&RPPDQG. The OSC message to request allocation of a Buffer filled with data from a sound file is as follows: EBDOORF5HDGEXIQXPSDWKVWDUW)UDPHQXP)UDPHV . and only the main code paths are indicated to aid understanding. This process is summarized in figure 26.8. This is achieved by deferring freeing the old sample data array until after the new one is installed into the RT context’s P6QG%XIV array. We now consider the steps performed at each stage of the execution of%XI$OORF 5HDG&PG. These stages are depicted in 4 sequence diagrams. It is important that the old sample data array is not freed until we can be certain no 8QLW is using it. The exact function parameters have been simplified from those in the source code.5 through 26. are picked up by dependent Units when their UnitCalcFunc is called. beginning with the arrival of an 26&B3DFNHW in the real-time context. The code may reallocate an existing SndBuf’s sample data array. figures 26.4.

735 26 Inside scsynths Figure 26. Stage 1 (see figure 26.4 Overview of multithreaded processing of the EBDOORF5HDG command. in this case PHWKBEBDOORF5HDG .5): The real-time context processes an OSC packet containing the EBDOORF5HDG message. The OSC dispatch mechanism looks up the correct function pointer to invoke from J&PG/LEUDU\.

. PHWKBEBDOORF5HDG .

calls &DOO6HTXHQFHG&RPPDQG .

&DOO 6HTXHQFHG&RPPDQG . to instantiate a new %XI$OORF 5HDG&PG instance (a subclass of 6HTXHQFHG&RPPDQG) which we will call FPG.

QLW . calls FPG!.

. which unpacks the parameters from the OSC packet and then calls FPG!&DOO1H[W6WDJH .

. which in turn invokes FPG!6WDJH .

It then enqueues FPG to the NRT thread. using 6HQG0HVVDJH)URP(QJLQH .. which in the case of %XI$OORF5HDG&PG does nothing.

with 'R6HTXHQFHG&RPPDQG as the )LIR0VJ )XQF. the P)URP(QJLQH FIFO is processed in the NRT thread. Stage 2 (see figure 26. The )LIR0VJ containing our FPG is processed.6): Some time later. which results in FPG!6WDJH .

being called via 'R6HTXHQFHG&RPPDQG .

and FPG!&DOO1H[W6WDJH .

cPG!6WDJH ..

does most of the work: first it calls :RUOGB*HW157%XI .

which retrieves a pointer to the NRT copy of the 6QG%XI record for FPG!P%XI.QGH[.. Then it opens the sound file and seeks to the appropriate position. Assuming no errors have occurred. Then DOORF%XI . the pointer to the old sample data array is saved in FPG!P)UHH'DWD so it can be freed later.

FPG!&DOO1H[W6WDJH . is called to update the 6QG%XI with the new file information and to allocate a new sample data array. Finally. A shallow copy of the NRT SndBuf is saved in FPG!P6QG%XI. The data are read from the file into the sample data array and the file is closed.

only this time in the real-time context.7): Similarly to stage 2. enqueues the FPG with the real-time context. FPG!6WDJH . Stage 3 (see figure 26.

is called via 'R6HTXHQFHG&RPPDQG .

and FPG!&DOO1H[W6WDJH .

. A pointer to the real-time copy of the 6QG%XI for index FPG!P%XI.QGH[ is retrieved .

736 Ross Bencina Figure 26.5 Stage 1 of processing the EBDOORF5HDGcommand in the real-time context. Figure 26. .6 Stage 2 of processing the EBDOORF5HDG command in the non-real-time (NRT) context.

737 26 Inside scsynths Figure 26.7 Stage 3 of processing the EBDOORF5HDG command in the real-time context.QGH[. using :RUOGB*HW%XI FPG!P%XI.

At this stage the sample data array which was allocated and loaded in stage 2 is now available to Units calling :RUOGB*HW%XI .. and the 6QG%XI instance data initialized in stage 2 is shallow copied into it from FPG!P6QG%XI.

. FPG!6WDJH .8): Once again. FPG is then sent back to the non-real-time thread. Stage 4 (see figure 26. back in the non-real-time thread.

Then the 6HQG'RQH . which frees the old sample data array which was stored into FPG!P)UHH'DWD in stage 2. is invoked.

which sends an OSC notification message back to the client who initiated the Buffer allocation. routine is invoked. which will cause FPG to be freed.2.4 Processing and dispatching OSC messages The 3URFHVV26&3DFNHW . 26. Finally.3. returning its memory to the real-time $OORF3RRO. FPG is enqueued back to the real-time context with the )UHH6HTXHQFHG&RPPDQG )LIR0VJ)XQF.

It makes use of P'ULYHU/RFN to ensure that only 1 thread is writing to the P2VF3DFNHWV7R(QJLQH queue at any time (this could occur. for example. when multiple socket listeners are active). To inject an OSC packet using 3URFHVV26&3DFNHW . function provides a mechanism for injecting OSC messages into the real-time context for execution.

. the caller allocates a memory block using PDOORF .

by reading from a network socket).. and then calls 3URFHVV26&3DFNHW . fills it with an OSC packet (for example.

 3URFHVV26&3DFNHW ..

using IUHH . takes care of enqueuing the packet to the P2VF3DFNHWV7R(QJLQH queue and deleting packets.

once they are no longer needed.. .

Once the real-time context processes OSC packets.738 Ross Bencina Figure 26. When integer command indices are received. however.8 Stage 4 of processing the EBDOORF5HDG command in the non-real-time (NRT) context. Once a scheduled packet has been processed. packets whose time-stamp values are in the future are stored in the P6FKHGXOHU 3ULRULW\4XHXH for later execution. OSC commands sent to the server may be strings or special OSC messages with a 4-byte address pattern in which the low byte is an integer message index. scsynth dispatches OSC commands by looking up the 6&B&RPPDQG)XQF associated with a given OSC address pattern. they are usually freed using the 0VJ)LIR message-freeing mechanism. Command strings are compatible with any OSC client. At startup 6&B0LVF&PGVFSS wraps these functions in /LE&PG objects and stores them into both the J&PG/LE hash table and J&PG$UUD\ array. 3HUIRUP26&0HVVDJH . whereas the integer command indices are more efficient but don’t strictly conform to the OSC specification. it is sent to the NRT thread to be freed.

26. The P7ULJJHUV . and P'HOHWH*UDSK'HIV FIFOs are used by the realtime context to enqueue notifications which are translated into OSC messages in the NRT thread and are sent to the appropriate reply address by invoking 5HSO\$GGUHVVP5HSO\)XQF.2. looks up the appropriate 6&B&RPPDQG)XQF in the J&PG$UUD\ array.5 Fixed-size data structures In real-time systems a common way to avoid the potential real-time unsafe operation of reallocating memory (which may include the cost of making the allocation and of . otherwise it consults the J&PG/LE hash table. P1RGH(QGV .3.

As always. This fixed-size allocation strategy is adopted in a number of places in scsynth. each containing 4 chars.739 26 Inside scsynths copying all of the data) is simply to allocate a “large enough” block of memory in the first place and have operations fail if no more space is available. 2007) they typically provide close to constant performance so long as they don’t get too full. while others are more like clever optimizations which help the server to run faster. Some of these fall into the category of low-bounded complexity methods which contribute to the real-time capabilities of the server. you can relaunch the server with larger sizes as necessary. but if your usage of scsynth causes any of the default limits to be exceeded. The sizes of many of these fixed-size data structures are configurable in :RUOG2SWLRQV (in general. • Hash tables in scsynth are implemented using open addressing with linear probing for collision resolution. the idea being that the default values are usually sufficient. including the size of • • • • FIFO queues which interconnect different threads P$OORF3RRO (the real-time context’s memory allocator) The P6FKHGXOHU priority queue for scheduling OSC packets into the future The P1RGH/LE hash table. when combined with a good hashing function (Wang. so looking at the source code will reveal many more optimizations than can be discussed here. a number of those which I have found interesting are briefly noted below. • The :RUOG uses a “touched” mechansim which Units and the AudioDriver can use to determine whether audio or control buses have been filled during a control cycle: • .4 Low-Level Mechanisms As may already be apparent. however. Although these tables don’t guarantee constant time performance in the worst case. consult the source code for more details. Of course the whole server is implemented efficiently. which is used to map integer 1RGH IDs to 1RGH pointers. 1RGHV 26. the implementation improves the efficiency of comparison and other string operations by being able to process 4 chars at once. This improves performance when resolving collisions during item lookup. by command line parameters). In the case of P1RGH/LE the size of the table determines the maximum number of the server can accommodate and the speed of 1RGH lookup as P1RGH/LE becomes full. scsynth gains much of its power from efficient implementation mechanisms. Aside from being the same format that OSC uses. • One optimization to hashing used in a number of places in the source code is that the hash value for each item (such as a 1RGH) is cached in the item. The Str4 string data type consists of a string of 32-bit integers.

For example. in the P$XGLR%XV7RXFKHG array for audio buses) to P%XI&RXQWHU. • Delay lines typically output zeros until the delay time reaches the first input sample. The delay unit generators in scsynth (see 'HOD\8*HQVFSS) avoid this time-consuming (and hence real-time unsafe) operation by using a separate UnitCalcFunc during the startup phase. it sets the corresponding touched field (for example. If not. %XI'HOD\1BQH[WB] . One way to handle this is to zero the internal delay storage when the delay is created or reset.740 Ross Bencina maintains the P%XI&RXQWHU. When a Unit writes to a bus. the data doesn’t need to be copied and zeros can be used instead. which is incremented at each control cycle. Readers can then check the touched field to determine whether the bus contains data from the current control cycle.

outputs zeros for the first EXI6DPSOHV samples. at which point the UnitCalcFunc is switched to %XI'HOD\1BQH[W .

there are separate functions for adding an audio vector to a constant. %LQDU\2S8JHQVFSS defines UnitCalcFuncs which implement all binary operations in separate versions for each rate type. For example. which outputs the usual delayed samples. • For rate-polymorphic units. the dynamic nature of UnitCalcFuncs is used to select functions specialized to the rate type of the Unit’s parameters.. DGGBDL . For example.

DGGBDD .. and adding 2 audio vectors.

When the binary-op 8QLW constructor %LQDU\2S8*HQB&WRU ..

is called. it calls &KRRVH1RUPDO)XQF .

R. D.” <http://g. I invite you to explore the source code yourself. :RUOG This concludes our little journey through the wonderful gem that is scsynth. 2000. T. and J. Reading. 2002. MA: Addison-Wesley. . Johnson. 2008). 1997. Lea. J. and it’s free! References Gamma. “Rethinking the Computer Music Language: SuperCollider.htm> (accessed January 9. Helm. Vlissides.concentric.net/~Ttwang/tech/inthash .. McCartney. 2008). “A Memory Allocator. Wang.” Computer Music Journal.edu/dl/html/malloc. E. R. “Integer Hash Function. 26(4): 61–68. to select among the available UnitCalcFuncs based on the rate of its inputs. it has much to offer.” <http://www.html> (accessed January 9. 1995. Design Patterns: Elements of Reusable Design.oswego.

.

.

.

.

28–36. 258. 65 BPF (Band pass filter). 17. 578. 741–742 Carrier (phase modulation). 254. 626 TempoClock. 210–211. 659. 24–29. 653 Ambient Lights (project). 12-Tone Matrix. 599 inside a method. 165. 89 ASCII. 607–608 for pitch extraction. 710. 122 Arduino. 367–372. 287. 742 Class (classes). 3. 57. 34–37. 34–35 Abstraction. 385. See also chapter 19 Bipolar. 644. 120–124 Arguments. 101. See also chapter 7 Additive Synthesis. 83–84. 163. 31–33. 15–16. 240. 61. 67. 11–14. 424–425 Analysis FFT.Subject Index This index includes topics from the main body of the text. 431 real time. 282. 420–422. 694–695 Clock (class). 362 Association. 148–149 Array. 550 Byte Code. 195. 549. 712–723. 83. see the syntax appendix. Ubiquitous topics have been limited to principal references. 508–509 Char. 57–60. 205. 228 AppClock. 122. 582–586. 65. 168–172 as object models. 161–162 as pattern. 480–484. 483. 128. 12 Beat Tracking. 83–84. 178. 697–704. 184. 725. 128. 441–442 synthesis. 56. 246. 420. 61. 146–147. 43. 65 UGens. 151. 676–679 C++. 76. 440–446 signal. 737 Bus. 25. For definitions of terms. 56. 80. 241–243 tree. 261. See Filter Buffer. 121. 731–734. 115. 120. 25–36. 87. 6–10. 118 Ambisonics. 742–744 nested. 21. 12 Binaural. 55. 20. 173 writing. 538. 128 AIFF. 234. See Machine listening Binary. 45 Cents. 197–202. 560. 219. 460. 390. 483–485 Algorithm (algorithmic). 626 SystemClock. 128–130. 744 Audio rate. 640. 65 Boolean. 200. 478– 480 . 196 Balancing enclosures. 560 composition. 42. For messages and classes from the SC language. 132–133. 42–46. see the code index. 56–57 indexing. 6. 645 Cloud (CloudGenerator). 23. 357. 83. 642 operators. 133–134 numbers. 238–240 literal.

28–29. 12. 134. 4. 61–62. 47. 648 variables. 417. 277. 139 Evaluation (of code). 557–564 Enclosures. 48. 432. 115. 10–11. See Patterns. 698. 494 Document Emacs. 197. 346. See Libraries External devices. 25. 91 DAW (Digital audio workstation) Composition (see Composition. See chapter 4 FFT. 17. 659–660 networked live. 664–666 Composition. 14. 62. 635–637. 69. 429. DAW) DC (offset). 64. 356. 151. 432–433 server side. 285 Fourier. See Modulation. 10–11. 122. 659–660. 50 Lag (Lag2). 61. 239 Flow control. 55. 401. 55. 152. 122 Ringz. 62. 81. 146. 288 Emacs (scel). 146 Event. 212 LeakDC. 241–243 PatternProxy. 152 return. 419 Function. 41. See External devices Dialects. 603–605 streams. 185. 684–685 Gate. 397. 17. 5. 357. 163. 465–469. 79–80. 373 OS X GUI (Cocoa). 375 CocoaDocument (see Document) Coding conventions. 120–124. 3. chapter 6 note (keys). 61. 130 Drag and Drop. 12 Envelope. 26. See also chapter 23 Dialogue (windows). 165 Distortion. 345 Flange. 68–70. 52. 353 RLPF. 162–165 Comb (N. 108. 11–14. 692–693 Median. 68. 7. See also Patterns. 402 LPF. 428–436 Delay. 72–76. 56. 361. 717 Decorrelation. 264. 196 ControlSpec. 61. external. 97 Granular synthesis. 417 Frequency modulation (FM). 225–230 triggering. 325. 93 object oriented (see chapter 18) Compression. 80 BPF. 302 Dictionary. 80 Combinatorics. 671 iterating. frequency FreeVerb. 160–162 FlowLayout. 53. 80. 141. 11. 480–483 . 55 Extensions. 220–221 protoEvent. 99. 417 CPU (usage). 76. 114. 79–80. 139. 28. 366–374 Encapsulation. 202–205. 230 Comments. 184–189 as object models. 118. 703 Float (floating-point). 230 scsynth style. 80. 343. 659–660. 18. 60. See also Microsound client-side. 87. 36. 18. 25. 415–417 Devices. 695. 718–719 Crucial library. 76. 128. 60. C). 130–131. 414 Environment. 147 FunctionDef. 38. See chapter 23 Control rate. 122 Klank. L. 151 Gestures. 440–442 Filter. 180–182. 220–222. 62. 62 Conductor. 722 Collection. 231–232. 166–167. 349. 355–357. 212 HPF. crucial Csound. 716–717 Debugging. 299–303 Dot (receiver dot message). 719 Compilation (compiler). 99. See Libraries. 143–144. 345. 80. 723 Cue Players.746 Subject Index Cocoa. 258. 193–197. 279 Convolution. 144 Garbage collection. See chapter 3 DAW style. 132. conductor Constraints.

603–607 crucial. <. See Filter Human Interface Devices. See chapter 22 Java. 303. 132. See Precedence GUI (Graphical user interface). 185. 55. 648 JSCUserView. 208–209. 69. See 12-Tone matrix . 419 Harmonic spectrum. 212 LazyEnvir. 603. See HID IdentityDictionary. 351 quarks. 3–4. 303 dewdrop_lib. 141 Literals. See also ==. 140–141 Introspection. harmonic series HID (Human Interface Devices). 56. See Machine listening Keyboard and Mouse. 589–611 extensions. 395 Key Tracking. 298–299 dynamically generated. 218 LPF (Low pass filter). 307. and. 205. 243 HPF (High pass filter). 240. See GUI Juggling. See also chapter 12 ALSA. See Filter Mac OS X. 211. 624–628 JACK. 62. See also Platforms. 572 Linux. JACK Japan. See chapter 20 ListPattern. See Linux. 452 onset detection. 68. 644–647 History. 130. 417. 365 HierSch. 62. 129. 68–70. 326–329 JITLib (Just In Time). 11. 291–294 static (singleton). or in code index Loop. 183 If (statements). 102. 65. 490–500 Grouping. >. 128–309. 79. 371–372 JACK. 679–685 variables. 319–321 OS X. 108. 105–111 Linux. 741 Klank. 615 Linear. 12-Tone. 74. 180. 614–619. 76. <=. 401–405 Markov. 274–276 SCUser. 450–452 key tracking. !=. 152–153 ixiQuarks. 315–319. 65. 385 Logical expressions. 215. 646 LeakDC. 546. 168–171 Instance methods. 28–31. See Interpolation Linux. 659 chucklib. 295–297 Emacs (see chapter 12) JSCUserView. See Spectrum. 633 Iteration. 359–360 platform specific. 122–124. 129–130 Localization. introspection iPhone. 230–235. 16. See Flow control Inharmonic spectrum. 182. chapters 9–12 cross-platform. 719–720 Windows (platform). See Spectrum. 246. See Filter Lag (Lag2). 41 Matrix. 153. 139 Instance variables. 25–30 infinite. 165–166. 106. 298 SwingOSC (see chapter 10) tuning. 489–490 wave sets. 137. 480. instance Interpolation. 171. inharmonic Inheritance. 362–363 Live performance. 363–365 introspection. 79–80 Interpreter.747 Subject Index sound files. 33. 163. 446–450 transcription. See Platforms Machine listening. 349 GVerb. 529 windows. 385–386. 452–453 Map (Mapping). See Filter Libraries C. >=. 58. See chapter 15 beat tracking. See Linux. See Variables. 286–287 Keywords.

228 Quarks. 215. 237–238. 61. 74. 431. 31 Mono (Monophonic). 30–35. 24. 57–58. 31. 61–64. 37. 228 modulation (see Modulation. 12. 359. 662. 411–414 Parallel FX. 57. 38. 79. 133–134. 437 Programming. 164 Optimization. 189–195. 128 layout. 737 Panning. 139 nested. 305. 368 NodeProxy. 105. 25. 190 parameter choices. 219 proxy. 197. 608. 352–353 QCD (quantum chromodynamics). 598–602 ProxySpace. 74. 31–32. 62. 375. 16 phase. 43. 15. 8–12 Method. See also Events. 20–21. 17. 8. See Machine listening Open Sound Control. See Platforms OSC (Open Sound Control). See also ixiQuarks Random button. 668. 594–595 MIDIResponder. See chapter 25 Polymorphism. 8. 200–201 empty. See Granular synthesis. 385–386. 29. 72. 308. 132. 134 Precedence effect. 90 pseudo. 105. 14. 15. 230. 637 Precedence. 68. 564. See chapter 5 Primitives. 89. 660–664 modeling (see chapter 8) oriented composition (see chapter 18) oriented programming. 79. 343 Platforms Linux (see chapter 12) Max OS X (see chapter 9) Windows (see chapter 11) Plug-ins. 457. networked live Nil. 252–258 Quantization. 404 NodeProxyEditor. 435 Physical Model. 226 recursive. 130–131 chains. 62. 442. 228 Noise. phase) spectrum decorrelation. 172 Microsound. 89. 265–266 collection (array). 592–593. 316. 385. 130. 718 OS X. %). 3. 168. 538. 211. 595. chapter 6 conductor. 684–689 Prototypes. See Message MetaClass. 11. 210–217. 72. See Keyboard and Mouse Multichannel (expansion). 644 Pink Noise. 13–14. 221–222. 28. 114. See OSC Operators. 643 index. 128. 156. 710 patterns. 660 Median. 130 instance. 672–705 Node. 65. 80. 104. 58. 411–412 Mouse. See Filter Message (method). 589. 87–88. 228. 261–262 (see also rrand in code index) seed. 14. 611 MIDIIn. 205. 79 frequency. 127–129 Offset. 104. 59–61. 105. 14. 199. 120 Modulo (Mod. 30–33. See Coding. 111–114. 345 PySCLang. 184–185. 56. chapter 16 MIDI. 47 pulse-width. 162 number generators. 220–222. 69 server side 68–69. 137. 410–413 Nesting. 28 Patterns. 87. 42–48 Onset detection. 431 Nyquist. 222 Phase. 411.748 Subject Index Max/MSP. 18. 595 Modulation. 716–717 Object(s). 8–12 Networked live coding. 710 range. 12. 189–190 .

269. 72. 280. 14. 489–490 scel. 349 Shout Window. 311–314 Smalltalk. 15–16. See Filter RLPF (Resonant low pass filter). 326–328 node. 287 Unipolar. See GUI Symbol. 698. See UGen UNIX. 47. See Filter Routine. 360–361 USB. 236. 49. 53. 45–47. 330. See also chapter 18 scsynth. 505–509 just. 196. 28. 80. 51. 33–35. TempoClocks Transcription. 68.749 Subject Index Ratios. 129 streams. 142 Reverb. See chapter 14 3D audio. 34. 371. 21–24. 38–41 SerialPort. 115–117. 207. 43–48. 211–214 options. 445. 262–265 Tempo clocks. 85–90 TaskProxy. 252–258. 4. 41. 644–647 sclang. 10. 386. 340–341. 65 Unit Generator. 95 Windows (platform). 153–155. 74 synthesis. 3. 641. 83–87 constraints. 179–180. 417–420 Ringz. 222 Synth Definitions. 167 microtonal (see chapter 17) Scale (relative size). 120–121 . 303 SCWindow. 119. 274–276. 409. 29–32. 691 UI. See Emacs Scheduler. See Clock. 10. 645 Scheduling. 420–421 Spectrum. 360–362 Scope. 106. 291. 87. 41. 22–24. 59. 197 SCView. See Variables. 79 Sample rate. 403. non-real-time. 117. 517 poly. 301. 39–41. See also chapter 2 and chapter 25 pseudo. 65. 603–604. See chapter 18 Task. 528 inharmonic. 306–307. 614. See also chapter 26 freeing. 62 SharedIn. 61. 46 Slider. 441. 307–308. 665 Receiver. 95–98 References. 106. 12. 31. See chapter 17 equal. 315–320. 347–352. See GUI Unicode. See also chapter 6 Synthesis. 432–435 harmonic series. 6. 515–516 odd Limit. 366 Streams. See Flow control SwingOSC. 115–116. See also chapter 13 Spatialization. 121 Server. 608–610 time. 638. See also Patterns String. 519–521 ratios. 515 tonality Diamond. 375. 23. 55–56. 349 Shaper. 518 unequal divisions. 83. See Machine listening Tuning. 109. 405 diffusion. 102. 93. 83–84. 44–46. 34 StartUp. 52–53 window. 55–69. 635. 515 UGen (Unit Generator). 57. 570 Sonification. 708–709. See Tuning Rate audio (see Audio rate) control (see Control rate) sample (see Sample rate) Recursion (recursive). 225–227. scope Score. 10. 87–91. 11. 5 Switch (statements). 28. 305–307. variable. 130 Recording. 24. 274 Sequences (Sequencer). 60. 98. 243–255 Sidebands. 361 Subtractive Synthesis. 20. 607 Sample and Hold. 734 Scale (collection of notes). 128. 237–240. 215–218. 34. 199–202.

17 Wacom. 140 scope. 202 interpreter. 124 Wave Field Synthesis. 11. 163–164 Wii. 111. 323–324 VEP (Virtual electronic poem). 155–156 versus references. 109–110. 18–23. 357 Window as GUI. 575–587 View. 166. 106. 156–158. 25. 139 environment. 137–140. 274–275 shout (see Shout window) Windows (platform). See Granular synthesis Wavetable. VCA). 31. 106.750 Subject Index Variables. 592–594 Voltage Control (VCO. 169. 142 VBAP (Vector based amplitude panning). See GUI Voicer. See also chapter 12 . 109. 140 pseudo. 135–141 class. 3–4. 139 instance. 425–427 Wave sets. VCF.

33. While most terms are used throughout the text. 522. 418 Messages  . typically from the tutorial chapters. this index is limited to initial references. 92. 26. 107. Note that this index is divided into two sections: messages and classes. 313 . 709  PRGPRGXOXV. background. 244–247 bufnum.Code Index This index contains language elements of SuperCollider.

101. 66. 86. 531–532 asStream. 111. 142 at (accessing elements of a collection). 321 dbamp. 70. 215–216. 63. 564 . 100 class. 365 control. 83. 73 choose. 500–503 asString. 4. 32. 256. 4–16. 244–247. 641 clock. 345 amp. 185 SwingOSC. 141. 89. 120. 204. 260–267 curve. 39. 455 and. 176 cpsmidi. 94 . 134. 38–40. 502 collect. 132. 30. 197. 364. 498. 220–221. 154. 313. 134. 651 . 86. 11. 98 def. 94. 30. 296 default Server. 147. 193. 302 asInteger. 204 close. 219. 29–30. 306–307 TempoClock. 120. 113. 63. 513 delta. 91–94. 250 clip. 174 abs. 529–530 asAscii. 27–28. 42. 312. 488. 494 ampdb. 33 !. 120 asCompileString. 31–33 ! . 69. 159. 24. 402. 606. 330 clear. 255. 293. 13. 119. 133. 59. 135  . 221. 32–33. 171. 150 adsr. 262–263. 75–76 decorator. 398 add. 120. 66. 486. 42. 494 count. 251. 116. 176. 63–64 addAll. 31–33 . 22. 12. 283. 255 coin. 625 connect. 210. 324. 455 asKeyValuePairs. 32–33 ar. 296 copy. 203 audio. 58–59 asArray. 266–267 copyRange. 647 defer. 295 asr. 33. 92. 297 degreeToKey. 191 current.. 244–245. 58–59. 296. 172. 637. 201.

113 noteOn. 69–76 doOnce. 85 midiratio. 277 drop. 329 even. 556 min. 447. 399. 191. 448. 479. 620 newMsg. 107 gap. 328. 347 disconnect. 38–39. 455–456 getDate. 325. 101 nextLine. 247. 134. 30. 35–37. 161. 329. 262 max. 324. 554. 501. 69. 387. 388. 118. 625 get. 67. 387 dump. 117. 249. 515. 107–108 font. 434. 317. 216. 332. 448 getPaths. 567 items. 267. 479. 547. 551. 625 findBy. 295. 70 Mix. 324 mouseUpAction. 64. 651 kr. 476. 13. 241. 297 node. 362 isFloat. 88. 295. 321. 58–59. 644 lag. 364 insert. 595. 476. 18. 33 explin. 85. 430 do. 67. 388. 26. 324. 328.752 Code Index destroy. 335 free. 92. 26. 10. 152 fork. 605 linexp. 6. 266–267. 552. 33. 193–194 env. 140. 404. 63. 397. 257. 313. 596 id. 455. 231–232 key. 518. 481–488 dist. 524 linrand. 259. 216. 292 notEmpty. 233. 289. 455 mod (%). 63 freq. 6. 458 noteOff. 257. 329 nodeID. 77. 119. 26. 32. 108 init. 266 error. 50. 295 normalizeSum. 559–561 linen. 64. 289. 486. 11. 292. 99. 244–247 for. 152 forBy. 19. 531 not. 13. 159. 471. 251 isEmpty. 69. 333 if. 138. 83. 551. 539. 11. 328–329. 488 load. 555–556 front. 203. 174–176 midicps. 388. 302 gui. 32 index. 37. 346 dup. 277. 487 fill Array. 296 globalKeyDownAction. 97. 652 ir. 198. 335 device. 261. 113 numChannels. 541–548 next. 31–33. 302 global. 609 info. 145. 312. 506. 33 isInteger. 245. 434 make. 485 lfo. 326. 24–25 mouseDownAction. 204. 553. 335 numFrames. 268. 260. 600 getn. 14–17 fadeTime. 28. 616–617. 277 linlin. 544. 349 discretize. 548 loadCollection. 23. 321. 35. 33 isKindOf. 332. 257 includes. 605. 145 format. 49. 4–6. 66. 335 . 402 latency. 471 map. 551 envir. 51 interpret. 113. 78 duration. 290 embedInStream. 391 isClosed. 640 exprange. 216. 111. 30.

257 softclip. 150. 256. 365 value. 152 window. 130. 63 pop. 246. 40. 252 sum. 225 uid. 553. 11. 198. 150–151. 132–133 prClose. 32. 219. 224. 153 . 538 xrand. 176. 321 post. 239. 210. 66 rrand. 250 wrap. 119–120. 259–260 sendCollection.753 Code Index odd. 13. 330. 220–221. 40. 647 trace. 13–19 plot. 67. 29. 402 source. 494 silent. 11–13 range. 257 select. 214–215 pos. 39–40 postln. 13. 422. 87. 92. 69–78. 512 string. 326. 295. 69. 69. 150 quant. 63. 302. 716 play. 267 pyramid. 45. 433 slice. 620 send. 99 reciprocal. 119 valueArray. 333 put. 8. 71–76. 388. 221 sine. 32. 350. 481–488 sendMsg. 108. 13. 145–146 setn. 69. 649 setStarttime. 538–547 start. 18. 471 set. 101. 40 wrapAt. 257. 351 poll. 30–33. 48–50. 261–262 putAll. 433 sched. 204. 122. 203. 32. 101. 64. 388. 215 sourceCode. 58. 415 or. 35. 38. 86–95 stream. 88 startTime. 145 record. 28. 647 scope. 566 state. 244–247. 115. 11 pow. 285 wait. 25. 44. 96. 70 ratio. 32. 48–49. 145. 78. 244–247 visible. 24. 154 squared. 85–94 render. 553 signalRange. 13 phase. 132. 710 swing. 85 while. 39–40 write. 116. 44. 398 standardizePath. 222 perc. 158–159 reverse. 11. 42. 83–84 schedAbs. 86. 63 scramble. 137. 84. 335. 33 path. 204. 84. 260. 95 register. 171 valueEnvir. 263 rand. 350 sampleRate. 195 reset. 13 rotate. 349. 59. 418. 333. 64. 95. 308 stringColor. 150–162. 91. 329 release. 149 sum3rand. 39. 35. 350. 31–35. 162 run. 259. 153 option. 202 wrapPut. 23. 82 permute. 233. 86. 183. 266 stop. 142. 346. 113. 13 round. 335 pause. 26. 64. 533 read. 376 tempo. 167 view. 88. 454 sendBundle. 398. 59. 410. 228. 140. 33 onClose.

69. 69 LFNoise (0. 73. C). 36. 708. 426 Blip. 197. 26. 415 BufDelay (N. 368. 63 Convolution. 496 BufSampleRate. 212. 388 Linen. 43. 490 Buffer. 29. 119. 637. 153 FFT. 155–159. 68. 19–21. 49. 50 Lag (Lag2). 99 Dictionary. 83.754 Code Index Classes Allpass (N. 63. 17–20. 626 CocoaDocument. 111. 10. 458 MIDIIn. 91. 77–78. 69. 364 Mix. 70. 19. 26–30. 139–142. 63 FSinOsc. 19. C). 197 LinExp. 39 Dialog. 68–69 KeyCodeResponder. 50. 138 Environment. 371 ExpRand. 450. 198 BufRd. 27–28. 166–167. C). 451 BiPanB2. 63. 24. L. 61 MouseX (MouseY). 418. 259 Function. 149. 353 In. 346. 63. 239. 14. 133. 140 LFDNoise3. 122. 487. 101. 62–63 Line. 350. L. 5. 49 LeakDC. 58. 180. 129. 61. 107. 111. 35–38. 171 GrayNoise. 76–78 Compander. 447 Char. 95. 13. 491. 231–233. 431. 239 Event. 28. C). 241 BPF. 444. 266–267. 350 Free. L. 106 KeyTrack. 696 IdentityDictionary. 97. 429. 625 MoogFF. 69. 122. 434 FlowLayout. 56. 64. 70. 245. 2). 38. 324. 17–19. 591 IRand. 64. 641 CmdPeriod. 402 LFClipNoise. 397 BrownNoise. 212. 663–667 Clip. 415–416 DetectSilence. 266 Harmonics. 416 AppClock. 458 MIDIOut. 277. 202. 299 Comb (N. 216 LFDNoise1. 616. 106. 311–312 EventStreamPlayer. 402. 77–78. 63–64. 13–14. 447. 87. 364. 397. 451. 83. C). 145 Limiter. 413. 159. 15–16. C). 388 Delay (N. 212. 97 EnvGen. 710 BufComb (N. 215 LFSaw. L. 5–6. 133 GUI. 164 HPF. 250. 198. 26–27. 422. 625 . 66. 246. 179. 453 Klank. 277 LinPan2. 204. 391 BeatTrack. 201. 15. 67. 547 Bus. 64. 334 Array. 389 MultiSliderView. 216 BufAllpass (N. 5. 744 Dust. 416 BufChannels. 623. 415 BufDur. 484 BufRateScale. 419 Decay. 8. 91. 43–45. 198. 1. 458. 212 Latch. 150. 247. L. 24. 287 KeyState. 175. 451. 351 LFTri. 59–61. 388. L. 140 LFPulse. 191. 414 LinXFade2. 413 LPF. 444. 507 BufFrames. 743 Impulse.

291–294 SCWindow. 101. 391 Saw. 111. 285. 299 SCCompositeView. 69. 180. 103. 715 PV_Copy. 8. 454–455 SampleRate. 63–78 Pan2. 209. 424 PlayBuf. 285 SCPen. 712–713 Rect. 596. 101. 388. 39. 345. 5. 215. 444. 25–30. 58–59. 122. 545. 647 Prout. 346 ProxySpace. 222. 73 Resonz. 431 PV_HainsworthFoote (PV_JensenAndersen). 606 Psym. 83. 389 Ramp. 39. 122. 69 RandSeed. 65. 162. 112. 231–232 Pan4. 251. 122 SendTrig. 605 Pmono. 413. 66. 445 . 609 PinkNoise. 205 Prand. 295. 89. 649 RLPF. 98. 73. 190. 345 Rotate2. 217. 192. 418. 116. 194 Pstutter. 283 Server. 446 PV_MagMul. 259 OSCpathResponder. 227. 223. 189–191. 69 RangeSlider. 116 Out. 190. 644 PopUpMenu. 189–194 Pseries. 345. 345. 15–16. 194 Ptuple. 62. 122. 87. 129–131 ReplaceOut. 232. 21–24. 58–63. 223 Pspawner. 195. 68. 180. 87–89. 295 NodeProxy. 190. 520. 75. 426 Patterns Pbind. 211. 388. 346. 507 ServerOptions. 190. 267 RecordBuf. 702 SCButton. 397. 328 OSCresponder. 231. 191. 231. 52. 289 SCUserView. 402. Pproto. 5. 5–7. 189 Ppar. 136 Node. 549 SinOsc. 620 RunningSum. 192. 240. 402 Rand. 606. 111. 97 Ringz. 6. 11. 182–183. 189–198 Pbrown. 228–233 Nil. 540. 107. 198. 4. 22–24. 444. 607 Pseq. 103. 423 PanB. 605. 291 SCSlider. 369. 198 PMOsc. 329. 547. 276–285 SelectX. 345 Pxrand. 229. 282. 189. 414 SendReply. 222 Ptime. 434 PV_Diffuser. 181–183. 335 SoundIn. 85. 281 SCTextField. 60. 229. 402. 388. 277. 95. 111. 65. 27–30. 606. 348 NRand. 192. 231. 595. 275. 295. 223–225. 92. 345 NoteOnResponder. 217. 231–232. 715 QuadN. 68 OffsetOut. 183 Pstep. 268 PriorityQueue. 122. 413–414 Routine. 221 Pwhite. 86. 350 SoundFile. 227. 91. 606–609 Pshuf. 648 PV_BrickWall. 625 RandID. 24. 413 PanAz. 101.755 Code Index Ndef. 67. 62. 434. 190. 69–70. 61. 414 SelectXFocus. 609 Pkey. 189. 95. 731. 353. 162. 609 Ptpar. 30. 62. 56–59 Slider2D. 396. 35–37. 344. 67. 455 OSCresponderNode. 431. 103 Pfunc. 65. 738 ProxyMixer. 440. 449. 192 Pdef.

414 StaticText. 109 Tdef. 293 . 422 SystemClock. 64. 17. 480–482 TIRand. 419. 67. 68–69 TRand. 185 TExpRand. 414 SplayAz. 417. 83–84. 19–21 TToggle. 549 TabletView. 25. 617–619 StereoConvolution2L.756 Code Index Splay. 176. 591 TGrains. 88. 215–220 TempoClock. 83–84. 268.