Tobias Kunze wrote:
> 
> > Well, yes, it's CLM that spurred me to make my comment about how Csound
> > doesn't truly *compile* the orchestra code. It seems like CLM, however,
> > does in fact do this, int the sense that it outputs a C source file
> > which codes the CLM instrument
> 
> yes. CLM takes the Lisp instrument definition and translates it to C
> source code.
> 
> > So in a sense, unlike C-sound, it is really a compiler
> 
> No. it writes a C source file, then calls the C compiler. It's not a
> compiler itself (although, historically, it used to compile to 65000
> DSP code, but I think that's now completely abandoned as host
> processors outperformed DSP's).
> 
Sorry, by "compiler" I meant something that generates code, not
necessarily machine code. So yes, I think that CLM can be considered to
compile its code into C. I didn't figure that the extra mechanical
detail of compiling the C into machine code disqualified CLM from being
a "compiler".

And to clarify what Csound is, I'm sorry if I said that it was an
interpreter, as someone said I did. Maybe I made reference to a
byte-code interpreter, in the sense that what csound generates as a
result of parsing the orch file might be loosely similar, in a way, to
byte-code, or p-code, in the sense that it is not code that can be
directly run, but needs to be run (interpreted) by some low-level
engine, which in this case traverses the linked-list of ugens, and calls
the ugen functions.

   
> > The not-so-cool thing about CLM, of course, is that there is only a
> > handfull of unit generators, compared to the immense richness of them
> > that Csound has.
> 
> *WHAT*?  Csound is a pathetic inflexible dinosaur when it comes to
> unit gens.  Yes, there are about 50, but face it, stuff like out, outa,
> outb,... etc are really only one.  CLM on the other hand has myriads of
> functionally different unit generators as you can see its home page.
> 

Hmm, that wasn't my impression. I had the feeling that csound has a lot
more critical mass in terms of contributions.I was under the impression,
from reading this list, that people have written ugens like Moog-style
filters, voice-box simulators (whatever that is), etc.

Actually, maybe it's the complete instruments that Csound has more of -
I see all the time on this list, people posting instruments, and there
is at least one repository of Csound instruments, as opposed to none
that I know of for CLM.

Don't get me wrong, I would rather stick to CLM, because its a much
nicer development environment, and better integrated with Common Music
than Csound is, but it still seems to me that for someone who might want
to start with some sound and then tweak it, that Csound has a lot more
"ready to go" instruments already contributed.
  

>  It is
> so annoying that I was willing to put up with Csound's pityful
> stoneaged assembler language and meager expressiveness. 

I assume that you're using Common Music, since you contributed so much
to it. What about designing some kind of Lisp wrapper over the Csound
orch syntax? 

 Just think
> about it: no useable if or even switch statements; horrible "goto"
> instead; you can convert sound to "spectral" data types but can't get
> it back; etc. Csound is horrible.  The only real advantage it had to
> me was that it did NOT compile!  :)  Running Csound with Cecelia does
> actually make a quite useful combination, IMO.
> 

Well, yes, of course the syntax is horrible - Csound is really a
re-incarnation of the MUSIC IV (or whatever the roman-numeral version #
is supposed to be) language. It *is* antique. I think a lot of the new
users of Csound might not be well-versed in computer-music history, and
get miffed when this tool that they are using has a very archaic syntax.
I can't wonder how much of this is due to that article in Keyboard mag a
few years ago. IOW, I wonder that because Csound as of late, has been
rather publicised, probably not just in Keyboard but in Linux magazine,
etc, that new-comers looking for a powerfull software synthesis program
will kind of a assume that this is leading-edge stuff, and not realize
it is some hacked and re-hacked piece of code a few decades old.



> -Tobias
> 
> ______________________________________________________________________
> 
> Tobias Kunze                     tkunze@ccrma.stanford.edu
> CCRMA, Stanford University       http://www-ccrma.stanford.edu/~tkunze

--  Larry Troxler --  lt@westnet.com  --  Patterson, NY USA  --