Michael Gogins wrote:
> 
> Why do I use Csound? I could write a software synthesizer myself, or I'd be
> willing to pay up to several thousand dollars for a software synthesizer.
> 
> I use it because I'd rather compose than program, and Csound can make cool
> sounds as it is; as long as I'm doing algorithmic synthesis and composition
> in the first place, it's got the most sounds and the largest community of
> users and the biggest library of patches.
> 

Yup, I hear you! Csound, by luck of the draw, got that critical mass
going.
At least it appears that way, judging purely based on the volume of mail
on the Csound list as compared with the mail for other synthesis
programs.
 
> And in fact it's not inefficient.
> 
> Earlier I said I dream about (a) fast SAOLC or (b) something like JSyn only
> with plugin opcodes. To this I would add (c) a reworked Csound with:
> 


Ok, maybe you missed my point, or maybe it's just too late in the night
for *me* to grok what you're saying. But when you talk about "plugin"
opcodes ...

All I was saying, is that Csound *interprets* the orch code, as opposed
to generating code which it then calls. The approach I'm talking about
would, I think, preclude the use of run-time-linked code, like "plugin
opcodes". Think of a C-compiler, which generates specific machine code.
Then think of the same thing, but compiling Csound orch code instead,
and then running it for a given score. The latter is closes to what
Common Lisp Music, for example, does. That's all I'm saying. I can't
believe that, for example, realizing a DX7 algo in csound, would be
anywhere near as fast as doing the same thing using CLM, which actually
generates C-code based on your instrument definition, then compiles it,
and calls it.
     
> 
> Open Source/CVS build model.
> 

Is Csound now public domain? The source code used to carry a copyright
notice, to the effect that distribution of derivative works were
prohibited without consent from MIT. Well, to be honest, I  *know* this
must have changed, but the version I downloaded from Bath just a couple
of years ago, *still* had this notice! What gives?
 
--  Larry Troxler --  lt@westnet.com  --  Patterson, NY USA  --

Larry Troxler wrote:

> All I was saying, is that Csound *interprets* the orch code, as opposed
> to generating code which it then calls. The approach I'm talking about
> would, I think, preclude the use of run-time-linked code, like "plugin
> opcodes".

Csound pre-processes the orchestra into linked lists of function calls.
The functions themselves are all compiled C.  The overhead isn't that
awfully high, especially if the K-rate is reasonable, reducing the
amount of time chasing from one link to the next by allowing each call
to process multiple samples.  In theory, this architecture should
make plugins simple to implement--just set the function pointer to
the dynamically-loaded plugin function.

> Think of a C-compiler, which generates specific machine code.
> Then think of the same thing, but compiling Csound orch code instead,
> and then running it for a given score. The latter is closes to what
> Common Lisp Music, for example, does.

There's certainly no reason why this sort of scheme couldn't call
a plugin--it wouldn't even need to be dynamically loaded.  Just
compile it (or an interface to it) along with the rest.

 That's all I'm saying. I can't
> believe that, for example, realizing a DX7 algo in csound, would be
> anywhere near as fast as doing the same thing using CLM, which actually
> generates C-code based on your instrument definition, then compiles it,
> and calls it.

Well, that likely depends upon the relative efficiency of the algorithms
used by each.  I doubt if either could come close to the performance
possible should someone write a DX7 emulator in, say, C...  There is a
price paid for generality, whatever the scheme used.

		-Ed