4 Jun
2004
4 Jun
'04
6:15 a.m.
Hi,
This subject reminded me that some time ago, a friend of mine mentioned
that he had read a message of James McCartney (SuperCollider) in which
James talked about his decision of having implemented his own OO
language for SC rather than reusing an existing, generic, OO language. I
looked for this message but could not find it, so I wrote James
directly, because I thought it might be an interesting addition to this
thread. James gave me a very extensive reply, which I forward to the
list.
Maarten
--------------------------------------------------------------------->8
Begin forwarded message:
Date: Thu, 3 Jun 2004 15:34:01 -0700
From: james mccartney <asynth(a)audiosynth.com>
To: mdeboer(a)iua.upf.es
Subject: Re: supercollider vs generic OO languages
I've included the original text file you are probably looking for below.
Here's some current remarks..
First of all I'm not sure many folks had heard about Python and
definitely not Ruby when I began writing SuperCollider in 1994. At that
time Python was not the language it is now. So those languages weren't
available as choices.
Second, neither of those languages are meant for real time. SC has a
real time garbage collector, constant time message lookup and various
other features designed for real time operation. Python uses reference
counting GC which has unbounded time cost when an object is freed.
Third SC was written specifically for writing music and audio processes.
The math system and behaviour of basic methods in the system were
designed for this. I looked into what it might take to make the Ruby
math system support building synthesis graphs the way that SC does, and
it did not seem like an easy thing to do.
I think that as languages SC is certainly comparable in strength to
Python and Ruby. SC has the most flexible argument passing of any of
them. Any or all arguments can be passed either positionally or by
keyword to any function. Keyword arguments can occur in any order.
Functions can be passed more or fewer arguments than defined.
Unspecified arguments can have default values. Functions can be called
with unspecified arguments bound dynamically in the caller's
environment. Excess arguments can be collected in arrays. SC has
closures and coroutines and is more consistent about their semantics
than either Python or Ruby.
SC's object model is based on Smalltalk but has also borrowed from
Scheme, NewtonScript, J, Icon. SC has borrowed some syntax features from
Ruby which happened to have co-evolved with a similar syntax.
SC no longer has to run at interrupt level as it did on OS 9, but many
of the issues for real time operation are the same.
Rather than struggle with a language not designed for real time they
should investigate using SuperCollider. It has been ported to linux.
----
SuperCollider 2.0
Why SuperCollider 2.0 ?
SuperCollider version 2.0 is a new programming language. Why invent a
new language and not use an existing language? Computer music
composition is a specification problem. Both sound synthesis and the
composition of sounds are complex problems and demand a language which
is highly expressive in order to deal with that complexity. Real time
signal processing is a problem demanding an efficient implementation
with bounded time operations. There was no language combining the
features I wanted and needed for doing digital music synthesis. The
SuperCollider language is most like Smalltalk. Everything is an object.
It has class objects, methods, dynamic typing, full closures, default
arguments, variable length argument lists, multiple assignment, etc. The
implementation provides fast, constant time method lookup, real time
garbage collection, and stack allocation of most function contexts while
maintaining full closure semantics. The SuperCollider virtual machine is
designed so that it can be run at interrupt level. There was no other
language readily available that was high level, real time and capable of
running at interrupt level.
SuperCollider version 1.0 was completely rewritten to make it both more
expressive and more efficient. This required rethinking the
implementation in light of the experience of the first version. It is my
opinion that the new version has benefitted significantly from this
rethink. It is not simply version 1.0 with more features.
Why use a text based language rather than a graphical language? There
are at least two answers to this. Dynamism: Most graphical synthesis
environments use statically allocated unit generators. In SuperCollider,
the user can create structures which spawn events dynamically and in a
nested fashion. Patches can be built dynamically and parameterized not
just by floating point numbers from a static score, but by other graphs
of unit generators as well. Or you can construct patches algorithmically
on the fly. This kind of fluidity is not possible in a language with
statically allocated unit generators. Brevity: In SuperCollider,
symmetries in a patch can be exploited by either multichannel expansion
or programmatic patch building. For example, the following short program
generates a patch of 49 unit generators. In a graphical program this
might require a significant amount of time and space to wire up. Another
advantage is that the size of the patch below can be easily expanded or
contracted just by changing a few constants.
(
{
// 10 voices of a random sine percussion sound :
s = Mix.ar(Array.fill(10, { Resonz.ar(Dust.ar(0.2, 50), 200 +
3000.0.rand, 0.003)}) );
// reverb predelay time :
z = DelayN.ar(s, 0.048);
// 7 length modulated comb delays in parallel :
y = Mix.ar(Array.fill(7,{ CombL.ar(z, 0.1, LFNoise1.kr(0.1.rand, 0.04,
0.05), 15) }));
// two parallel chains of 4 allpass delays (8 total) :
4.do({ y = AllpassN.ar(y, 0.050, [0.050.rand, 0.050.rand], 1) });
// add original sound to reverb and play it :
s+(0.2*y)
}.play )