<<

RSC3 FOR SCHEMERS: AN INTRODUCTION TO RSC3

ROHAN DRAPE

Abstract. These are notes for a talk addressed to Schemers about rsc3, a scheme client to the SuperCollider (SC3) synthesis server. This talk provides a brief history of in order to place SC3 in context and to define the problem domain, and then a description of and rationale for rsc3.

1. Musics I through V Mathews, working at AT&T, wrote the Music system in 1958 [1] and suc- cessive variants of this system through Music-V. Musics I through III were experi- mental and not used outside AT&T, Musics IV and V were written in Fortran and were the first widely distributed computer music synthesis systems, used for many years in studios including those at Stanford, Princeton, Columbia, MIT, IRCAM and Marseille. In 1969 Matthews published the important text “The Technology of Computer Music” [2] which is in two parts, the first discusses basic digital signal processing theory, the second is a manual for Music-V. at MIT wrote Music-11 [14] and variants through [15] which is highly portable and very widely used. Eric Scheirer and others at MIT wrote the MPEG4 structured audio specification [10], a variant of CSound. These systems are all considered to be part of a Music-N family.

2. The Music-N Paradigm Systems in the Music-N family are acoustical compilers, reading a set of instruc- tion files to generate a signal file. Users define a set of signal processing graphs called instruments that together form an orchestra. The nodes of the signal flow graph are called unit generators or UGens. UGens read and write continuous signals from unidirectional ports. For efficiency many Music-N systems provide three rates of signal flow, initialization rate i-rate, control rate k-rate and audio rate a-rate. instr 1 k1 linen p5,p6,p3,p7 a2 oscil k1,p4,2 out a2 endin

A piece is written by specifying a sequence of notes in a score. A note is a set of parameters, the first five parameters are traditionally instrument number, start time, duration, frequency and amplitude. i1 0 1 440 0.1 0.5 0.25 i1 0.5 1 442 0.1 0.25 0.5

Date: August 2003, minor revisions November 2006, May 2010, June 2014. 1 3. Other Computer Music Systems A different family of systems follow the Patcher [7] paradigm due to Puckette working at IRCAM. Systems in use include Max [8, 17], Pd [9]. A patch is a graph that combines both continuous signal processing elements and asynchronous messaging elements. This is at once the most interesting and problematic aspect of patcher systems. Patches are ordinarily created and edited using a drawing editor. Ideomatically the graph drawing represents the state of the system, however in practice graphs often become too complicated to be written in this manner and sub-graphs and references to stored data files are required. Another family of systems follow the Editor [6] paradigm, due to Moore working at Lucasfilm. These systems have direct precedents in analog studios and are very widely used in digital studios. Two widely used implementations are ProTools from Digidesign and Logic from Apple.

4. SuperCollider SuperCollider (SC) is a family of real-time audio signal processing systems writ- ten by James McCartney. SuperCollider is a descendant of Pyrite, a system for describing and generating Max patches. The first SuperCollider [3] is a dialect of Scheme highly optimized for musical signal processing. SC2 [4] and SC3d5 [5] are dialects of SmallTalk with the same optimizations. The interpreters for these languages generate real-time audio signals as a side effect of evaluating certain expressions. f = LFSaw.kr(0.4, 0, 24, LFSaw.kr([8,7.23], 0, 3, 80)).midicps; CombN.ar(SinOsc.ar(f, 0, 0.04), 0.2, 0.2, 4);

SC3 is a variant of SC2 that cleanly separates the language intepreter and syn- thesis engine into two processes. These processes communicate over network sockets using a subset of the Open Sound Control (OSC) protocol [16]. The SC3 synthesis engine, scsynth, manages a graph of instruments. Instruments are specified as byte strings. All operations on the graph are initiated by sending an OSC message over a network socket. OSC messages are timestamped using the Network Time Proto- col (NTP). Operations that are not atomic reply to the client when the operation completes. UGens are loaded dynamically when the system boots and can be writ- ten by users. The SC3 language interpreter sclang implements the same SmallTalk dialect provided by SC2. SC3 is efficient, well designed and well implemented.

5. Music-N, SC3 and Moore’s Law Earlier systems had provided high level languages for music signal processing by targeting Music-N systems. Common Lisp Music (CLM) [11] is one instance of this. The most significant contribution of SC is to real-time musical signal processing. Music-N systems were designed as accoustical compilers at a time when works were submitted to computer administrators on punch card and the output tapes were sent to a digital to analgue converter that rendered analogue tapes offline. Although traditional Music-N systems have been progressively adapted for real time environments the basic architectures are not properly dynamic. SuperCollider was initially designed as a high level language interpreter for real-time music signal processing. Correct dynamic behavior of the signal processing system requires: 1. graphs of instruments, 2. dynamic insertion and deletion of instruments at these graphs (this requires real-time constraints on UGen instatiation as well as runtime operation), 3. 2 dynamic audio and control signal routing and rerouting (global audio and control signal paths). Real time systems adapt to offline compilation use well.

6. Scheme As this paper is addressed to Schemers this section will be terser still. Scheme is a good working environment for music composition. Scheme is simple, dynamic, fast and well supported.

7. rsc3 rsc3 is an R6RS [12] library that facilitates using scheme as a client to the SC3 synthesis server. rsc3 is a client of the SC3 synthesis server in the same sense that sclang is. Where appropriate rsc3 provides a similar interface layer and uses the same or similar names and is therefore a derivative work of SC3. The rsc3 core implements: (1) The OSC protocol. A bytecode generator and parser for the subset of the OSC protocol used by SC3. (2) SC3 Synth Definition management. A bytecode generator and parser. Im- plementations for all UGens distributed with SC3. SC3 type input replica- tion (multiple channel expansion). (3) An Emacs [13] mode, with rsc3 and SC3 session management, expression evaluation, textual rewriting for evaluation, graph drawing and symbol lookup of rsc3 source and help files. The expressions below show the equivalent SC3 language and rsc3 declarations of a trivial Synth definition. Synthdef("sin", { arg f=440, a=0.1; Out.ar(0, SinOsc.ar(f, 0) * a); })

(synthdef "sin" (letc ((f 440) (a 0.1)) (out 0 (mul (sin-osc ar f 0) a))))

rsc3 provides a moderate set of procedures related to audio signal processing and musical composition. Using modern scheme systems thread latency is adequate for most musical work and GC stop times are reasonable though not ideal. The rsc3 source repository is available from: http://rd.slavepianos.org/.

8. Examples A series of examples demonstrate: the Emacs mode, partial UGen graphs, graph drawing, the dissasembler, the UTC and tempo schedulers, the widget set and control data integration.

References [1] M. V. Mathews. Computer Program to Generate Acoustic Signals. Journal of the Acoustical Society of America, 32:1493, 1960. [2] M. V. Mathews. The Technology of Computer Music. MIT Press, Cambridge, MA, 1969. [3] James McCartney. SuperCollider: a new real time synthesis language. In Proceedings of the International Computer Music Conference. International Computer Music Association, 1996. [4] James McCartney. Continued evolution of the SuperCollider real time synthesis environment. In Proceedings of the International Computer Music Conference, pages 133–136. International Computer Music Association, 1998. 3 [5] James McCartney. A New, Flexible Framework for Audio and Image Synthesis. In Proceedings of the International Computer Music Conference, pages 258–261. International Computer Music Association, 2000. [6] F. R. Moore. The Lucasfilm facility. W. Kaufmann, Los Altos, CA, 1985. [7] . The Patcher. In Proceedings of the International Computer Music Confer- ence, pages 420–429, San Francisco, 1988. Proceedings of the International Computer Music Conference. [8] Miller Puckette. Combining Event and Signal Processing in the Max Graphical Programming Environment. Computer Music Journal, 15(3):68–77, 1991. [9] Miller Puckette. . In Proceedings of the International Computer Music Conference, pages 224–227. International Computer Music Association, 1997. [10] Eric Scheirer. SAOL: The MPEG-4 structured audio orchestra language. In Proceedings of the International Computer Music Conference, pages 432–438, 1998. [11] William Schottstaedt. Machine Tongues XVII: CLM - Music V meets Common Lisp. Com- puter Music Journal, 18(2), 1994. [12] Michael Sperber, R. Kent Dybvig, Matthew Flatt, Anton Van Straaten, Robby Findler, and Jacob Matthews. Revised6 report on the algorithmic language scheme. J. Funct. Program., 19(S1):1–301, 2009. [13] Richard Stallman. EMACS: The Extensible, Customizable, Self Documenting Display Editor. Symposium on Text Manipulation, pages 147–156, 1981. [14] Barry Vercoe. Reference Manual for the Music 11 Sound Synthesis Language. MIT Studio, Cambridge, MA, 1979. [15] Barry Vercoe. Csound: A manual for the audio processing system. MIT Media Lab, Cam- bridge, MA, 1985. Revised 1996. [16] Matthew Wright and Adrian Freed. Open Sound Control: A New Protocol for Communicating with Sound . In Proceedings of the International Computer Music Conference, pages 101–104. International Computer Music Association, 1997. [17] David Zicarelli. An extensible real-time signal processing environment for Max. In Proceedings of the International Computer Music Conference, pages 463–466. International Computer Music Association, 1998.

4