The trouble is that if we use the term 'compiler' too librerally, it
ends up meaning everything and nothing. In my mind, Csound is really  a
scripting language. It doesn't 'compile into code', nor is it an
interpreter (there is no 'executable output'), it links
~already-compiled~ routines according to the users requirements. Output
is either a sounfile, or an audio stream. Even if we call Csound's
syntax 'assembler-like', there is still no machine-like code it compiles
into, as such, just linked lists of routines. Thus Csound was able to be
adapted to link SHARC dsp modules (pre-built), for XTCsound. Perhaps
this is a case where Csound ~is~ more of a compiler; though surely the
SHARC executable it produces requires a lot of support from the XTCsound
OS - and the ADI linker.


Conversely, I understand CLM to be (according to the given descriptions)
a language ~translator~ - it translates it's native language into C.
Presumably in the days when it produced 56K dsp code, it was linking
existing modules, rather than compiling directly into machine code.

If we call Csound ~or~ CLM 'compliers', then we really have to call web
browsers compilers too, simply because they take HTML and turn it into
pictures and text on a screen.

CLM looks like an attractive package; but it is from these descriptions
very much less self-sufficient than Csound. Nobody even needs to own a C
compiler to use Csound. For many users, that must be a major part of its
attraction, and hence its success. Composers can get into it step by
step, without having to have a full-scale computer-science-like
environment, with commandline c-compilers and the rest. If MIDI
sequencers depended on the availablility of a C compiler on everyone's
machine, I don't think they would be the commercial and musical
phenomenon they are!

Richard Dobson


-- 
Test your DAW with my Soundcard Attrition Page!
http://wkweb5.cableinet.co.uk/rwd