221 lines
12 KiB
HTML
221 lines
12 KiB
HTML
|
<!DOCTYPE html>
|
||
|
<html lang="en">
|
||
|
<head>
|
||
|
<title>rd: rsc3-texts/md/rsc3-for-schemers.md</title>
|
||
|
<meta name="description" content="rsc3-texts/md/rsc3-for-schemers.md" />
|
||
|
<meta name="author" content="ROHAN DRAPE" />
|
||
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
|
||
|
<link rel="stylesheet" type="text/css" media="all" href="css/rd.css" />
|
||
|
<link rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/gh/aaaakshat/cm-web-fonts@latest/fonts.css" />
|
||
|
<link rel="icon" type="image/png" href="https://rohandrape.net/data/png/rd.512.png" />
|
||
|
<meta name="viewport" content="width=device-width,initial-scale=1,user-scalable=yes" />
|
||
|
<meta name="google-site-verification" content="FRRDSM4lyfU-s4Pw9tAjg4mz_27hNAgSgGQuC2I-Hkc" />
|
||
|
</head>
|
||
|
<body class="rsc3-texts/md/rsc3-for-schemers.md">
|
||
|
<div class="main">
|
||
|
<nav class="menu">
|
||
|
<div class="menu">
|
||
|
rd:
|
||
|
<span class="menu" id="work">
|
||
|
<a href="?t=work" class="not-here">work</a>
|
||
|
</span>
|
||
|
<span class="menu-separator"> | </span>
|
||
|
<span class="menu" id="about">
|
||
|
<a href="?t=about" class="not-here">about</a>
|
||
|
</span>
|
||
|
<span class="menu-separator"> | </span>
|
||
|
<span class="menu" id="contact">
|
||
|
<a href="?t=contact" class="not-here">contact</a>
|
||
|
</span>
|
||
|
</div>
|
||
|
</nav>
|
||
|
<div class="rd-md"><h1>rsc3 for Schemers: An Introduction to rsc3</h1>
|
||
|
<p>Rohan Drape<br />
|
||
|
August 2003</p>
|
||
|
<blockquote>
|
||
|
<p>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 computer music in order to place Sc3 in
|
||
|
context and to define the problem domain, and then a description of
|
||
|
and rationale for rsc3.</p>
|
||
|
</blockquote>
|
||
|
<p>Max Mathews, working at AT&T, wrote the Music system in 1958
|
||
|
(Mathews1960a) and successive variants of this system through
|
||
|
Music-V. Musics I through III were experimental 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 <em>The Technology of Computer Music</em> (Mathews1969a) which is
|
||
|
in two parts, the first discusses basic digital signal processing
|
||
|
theory, the second is a manual for Music-V. Barry Vercoe at MIT wrote
|
||
|
Music-11 (Vercoe1979a) and variants through CSound
|
||
|
(Vercoe1985a) which is highly portable and very widely used. Eric
|
||
|
Scheirer and others at MIT wrote the MPEG4 structured audio
|
||
|
specification (Scheirer1998a), a variant of CSound. These systems
|
||
|
are all considered to be part of a <em>Music-N</em> family.</p>
|
||
|
<h2>The Music-N Paradigm</h2>
|
||
|
<p>Systems in the Music-N family are acoustical compilers, reading a set
|
||
|
of instruction files to generate a signal file. Users define a set of
|
||
|
signal processing graphs called <em>instruments</em> that together form
|
||
|
an <em>orchestra</em>. The nodes of the signal flow graph are called
|
||
|
<em>unit generators</em> or <em>Ugens</em>. Ugens read and write continuous
|
||
|
signals from unidirectional <em>ports</em>. For efficiency many Music-N
|
||
|
systems provide three rates of signal flow, initialization rate
|
||
|
<em>i-rate</em>, control rate <em>k-rate</em> and audio rate <em>a-rate</em>.</p>
|
||
|
<pre><code>instr 1
|
||
|
k1 linen p5,p6,p3,p7
|
||
|
a2 oscil k1,p4,2
|
||
|
out a2
|
||
|
endin
|
||
|
</code></pre>
|
||
|
<p>A piece is written by specifying a sequence of <em>notes</em> in a
|
||
|
<em>score</em>. A note is a set of parameters, the first five parameters are
|
||
|
traditionally instrument number, start time, duration, frequency and
|
||
|
amplitude.</p>
|
||
|
<pre><code>i1 0 1 440 0.1 0.5 0.25
|
||
|
i1 0.5 1 442 0.1 0.25 0.5
|
||
|
</code></pre>
|
||
|
<h2>Other Computer Music Systems</h2>
|
||
|
<p>A different family of systems follow the Patcher (Puckette1988a)
|
||
|
paradigm due to Puckette working at IRCAM. Systems in use include Max
|
||
|
(Puckette1991b, Zicarelli1998a) and Pd (Puckette1997a). 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.</p>
|
||
|
<p>Another family of systems follow the Editor (Moore1985a) paradigm,
|
||
|
due to Moore working at Lucasfilm. These systems have direct
|
||
|
precedents in analog studios and are very widely used in digital
|
||
|
studios. Two current implementations are ProTools from Digidesign
|
||
|
and Logic from Apple.</p>
|
||
|
<h2>SuperCollider</h2>
|
||
|
<p>SuperCollider (Sc) is a family of real-time audio signal processing
|
||
|
systems written by James McCartney. SuperCollider is a descendant of
|
||
|
Pyrite, a system for describing and generating Max patches.</p>
|
||
|
<p>The first SuperCollider (McCartney1996a) is a dialect of Scheme
|
||
|
highly optimized for musical signal processing. Sc2
|
||
|
(McCartney1998a) and Sc3d5 (McCartney2000a) 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.</p>
|
||
|
<pre><code>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);
|
||
|
</code></pre>
|
||
|
<p>Sc3 is a variant of Sc2 that cleanly separates the language intepreter
|
||
|
and synthesis engine into two processes. These processes communicate
|
||
|
over network sockets using a subset of the Open Sound Control (Osc)
|
||
|
protocol (Wright1997a). The Sc3 synthesis engine, <em>scsynth</em>,
|
||
|
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 Protocol (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 written by users. The Sc3 language
|
||
|
interpreter <em>sclang</em> implements the same SmallTalk dialect
|
||
|
provided by Sc2. Sc3 is efficient, well designed and well
|
||
|
implemented.</p>
|
||
|
<h2>Music-N, Sc3 and Moore's Law</h2>
|
||
|
<p>Earlier systems had provided high level languages for music signal
|
||
|
processing by targeting Music-N systems. Common Lisp Music (Clm)
|
||
|
(Schottstaedt1994a) is one instance of this.</p>
|
||
|
<p>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.</p>
|
||
|
<p>Correct dynamic behavior of the signal processing system requires:</p>
|
||
|
<ol>
|
||
|
<li>
|
||
|
<p>graphs of instruments</p>
|
||
|
</li>
|
||
|
<li>
|
||
|
<p>dynamic insertion and deletion of instruments at these graphs (this
|
||
|
requires real-time constraints on Ugen instatiation as well as runtime
|
||
|
operation)</p>
|
||
|
</li>
|
||
|
<li>
|
||
|
<p>dynamic audio and control signal routing and rerouting (global
|
||
|
audio and control signal paths).</p>
|
||
|
</li>
|
||
|
</ol>
|
||
|
<p>Real time systems adapt to offline compilation use well.</p>
|
||
|
<h2>Scheme</h2>
|
||
|
<p>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.</p>
|
||
|
<h2>rsc3</h2>
|
||
|
<p>rsc3 is an R6RS (Sperber2009a) library that facilitates using
|
||
|
scheme as a client to the Sc3 synthesis server.</p>
|
||
|
<p>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:</p>
|
||
|
<ol>
|
||
|
<li>
|
||
|
<p>The Osc protocol. A bytecode generator and parser for the
|
||
|
subset of the Osc protocol used by Sc3.</p>
|
||
|
</li>
|
||
|
<li>
|
||
|
<p>Sc3 Synth Definition management. A bytecode generator and
|
||
|
parser. Implementations for all Ugens distributed with Sc3. Sc3 type
|
||
|
input replication (multiple channel expansion).</p>
|
||
|
</li>
|
||
|
<li>
|
||
|
<p>An <em>Emacs</em> (Stallman1981a) mode, with rsc3 and Sc3 session
|
||
|
management, expression evaluation, textual rewriting for evaluation,
|
||
|
graph drawing and symbol lookup of rsc3 source and help files.</p>
|
||
|
</li>
|
||
|
</ol>
|
||
|
<p>The expressions below show the equivalent Sc3 language and rsc3
|
||
|
declarations of a trivial Synth definition.</p>
|
||
|
<pre><code>Synthdef("sin", {
|
||
|
arg f=440, a=0.1;
|
||
|
Out.ar(0, SinOsc.ar(f, 0) * a)})
|
||
|
</code></pre>
|
||
|
<pre><code>(synthdef "sin"
|
||
|
(letc ((f 440) (a 0.1))
|
||
|
(Out 0 (Mul (SinOsc f 0) a))))
|
||
|
</code></pre>
|
||
|
<p>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.</p>
|
||
|
<p>The rsc3 source repository is available from: <a href="http://rohandrape.net/?t=rsc3">http://rohandrape.net/?t=rsc3</a>.</p>
|
||
|
<h2>Examples</h2>
|
||
|
<p>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.</p>
|
||
|
<h2>References</h2>
|
||
|
<p>M. V. Mathews. Computer Program to Generate Acoustic Signals. <em>Journal of the Acoustical Society of America</em>, 32:1493, 1960.</p>
|
||
|
<p>M. V. Mathews. <em>The Technology of Computer Music</em>. MIT Press, Cambridge, MA, 1969.</p>
|
||
|
<p>James McCartney. SuperCollider: a new real time synthesis language. In <em>Proceedings of the International Computer Music Conference</em>. International Computer Music Association, 1996.</p>
|
||
|
<p>James McCartney. Continued evolution of the SuperCollider real time synthesis environment. In <em>Proceedings of the International Computer Music Conference</em>, pages 133--136. International Computer Music Association, 1998.</p>
|
||
|
<p>James McCartney. A New, Flexible Framework for Audio and Image Synthesis. In <em>Proceedings of the International Computer Music Conference</em>, pages 258--261. International Computer Music Association, 2000.</p>
|
||
|
<p>F. R. Moore. <em>The Lucasfilm digital audio facility</em>. W. Kaufmann, Los Altos, CA, 1985.</p>
|
||
|
<p>Miller Puckette. The Patcher. In <em>Proceedings of the International Computer Music Conference</em>, pages 420--429, San Francisco, 1988. Proceedings of the International Computer Music Conference.</p>
|
||
|
<p>Miller Puckette. Combining Event and Signal Processing in the Max Graphical Programming Environment. <em>Computer Music Journal</em>, 15(3):68--77, 1991.</p>
|
||
|
<p>Miller Puckette. Pure Data. In <em>Proceedings of the International Computer Music Conference</em>, pages 224--227. International Computer Music Association, 1997.</p>
|
||
|
<p>Eric Scheirer. SAOL: The MPEG-4 structured audio orchestra language. In <em>Proceedings of the International Computer Music Conference</em>, pages 432--438, 1998.</p>
|
||
|
<p>William Schottstaedt. Machine Tongues XVII: CLM - Music V meets Common Lisp. <em>Computer Music Journal</em>, 18(2), 1994.</p>
|
||
|
<p>Michael Sperber, R. Kent Dybvig, Matthew Flatt, Anton Van Straaten, Robby Findler, and Jacob Matthews. Revised6 report on the algorithmic language scheme. <em>J. Funct. Program.</em>, 19(S1):1--301, 2009.</p>
|
||
|
<p>Richard Stallman. EMACS: The Extensible, Customizable, Self Documenting Display Editor. <em>Symposium on Text Manipulation</em>, pages 147--156, 1981.</p>
|
||
|
<p>Barry Vercoe. <em>Reference Manual for the Music 11 Sound Synthesis Language</em>. MIT Electronic Music Studio, Cambridge, MA, 1979.</p>
|
||
|
<p>Barry Vercoe. <em>Csound: A manual for the audio processing system</em>. MIT Media Lab, Cambridge, MA, 1985. Revised 1996.</p>
|
||
|
<p>Matthew Wright and Adrian Freed. Open Sound Control: A New Protocol for Communicating with Sound Synthesizers. In <em>Proceedings of the International Computer Music Conference</em>, pages 101--104. International Computer Music Association, 1997.</p>
|
||
|
<p>David Zicarelli. An extensible real-time signal processing environment for Max. In <em>Proceedings of the International Computer Music Conference</em>, pages 463--466. International Computer Music Association, 1998.</p>
|
||
|
<hr />
|
||
|
<p>Minor revisions November 2006, May 2010, June 2014, June 2019, May 2021</p>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|