Subject: Re: [linux-audio-dev] SuperClonider
From: James McCartney (asynth_AT_io.com)
Date: Sat Apr 27 2002 - 01:09:38 EEST
OK I've been clued into this thread and will give my 2 cents.
First some error corrections. SuperCollider is a buffer computation
engine, not sample at a time.
I do have an experimental code generating version that does sample at a
time, which I talked about at Dartmouth, so perhaps that is where that
conception comes from. I will probably release it eventually or better,
a version merged with the block version. The block oriented engine is a
lot faster.
I do not have anything against Linux and I am not an Apple robot/zombie.
It has taken me some time to get SC ported to MacOSX. I'm still not done
with that. I have always said that after that I would look at a linux
port. I would like to do that.
A note about Cmix: its original author, Paul Lansky has been using
SuperCollider recently.
see: http://www.music.princeton.edu/~newton/group/past.html
My own idea of what the advantages of SC over MAX, pd, CSound, SAOL are
these:
SuperCollider is a fully object oriented language like Smalltalk, with
first class functions/closures and coroutines (like Scheme). If your
programming experience is only C,C++,Java and you've never used closures
and coroutines, then there is a level of expressive power there goes
beyond those languages. Also I think that SuperCollider has the most
flexible argument passing of any programming language. All arguments may
be specified either positionally or by keyword, or can default to a
value, or can be bound from a key-value pair in a current environment.
You can have variable length argument lists. You can pass too many
arguments or too few. This lets you be really promiscuous with your use
of functions.
I used MAX for a long time and after writing a text based language
object for it, I found that I did all my composition using that and used
MAX only for the GUI and the I/O. Most complex state oriented algorithms
can be stated much more briefly
in a sufficiently powerful language, and in addition will be much more
readable and maintainable than a bunch of boxes and wires. I've
performed live with MAX. I know all about that.
SuperCollider can build patches algorithmically and with a few lines of
code define complex patches. By expressing common signal processing
structures like parallel branches and sequential chains as code, patches
can be re-dimensioned easily. By not having to express all the redundant
information in patches with parallel structures, you
can write them more quickly and change them more easily. By being able
to describe structures using closures, you can build up a library of
components that cannot just be plugged together, but can functionally
manipulate the structure.
It would be impossible, practically, to duplicate the SC Patterns
library in MAX or pd. I know because before there was SuperCollider I
tried to write something like it in MAX. And it would be pretty hard to
do so in any language other than one with continuations like Scheme. The
patterns library is a way of representing any composition that can be
expressed as a sequence of events, as a lazy evaluated stream, and
provides ways of manipulating the stream in a functional manner. The
events contain key-value pairs for all the attributes of an event. The
dynamic binding of values in events to synthesis instrument arguments
insulates the composition from details of instrument implementation.
Like any tools there are some things you can do better with some than
with others. SC has not been good at some things historically like its
MIDI event handling. There are some areas that SC can do that the others
can't touch. I believe that, for algorithmic composition, nothing else
is better.
--- For a look at some docs, there is a set of them in html form from version 2.2.7 at: http://www.audiosynth.com/schtmldocs/index.html -- --- james mccartney james_AT_audiosynth.com <http://www.audiosynth.com> SuperCollider - a real time synthesis programming language for the PowerMac. <ftp://www.audiosynth.com/pub/updates/SC2.2.14.sea.hqx>
This archive was generated by hypermail 2b28 : Sat Apr 27 2002 - 01:13:46 EEST