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.

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:

All platform-specific code isolated in plugin inputs and outputs, i.e. the
Csound "engine" is plain simple ANSI C that is EXACTLY the same on all
platforms as near as that is possible.

Plugin opcodes and GENs.

A Java interface.

Some fairly drastic spaghetti reduction.

A better time/frequency analysis/resynthesis facility, along the lines of
Lemur or SMS orSoundHack.

The same old command options, orc language, sco language, and file formats
so that the library just keeps on getting bigger and better.

Open Source/CVS build model.


-----Original Message-----
From: Larry Troxler 
To: csound@maths.ex.ac.uk 
Date: Wednesday, February 24, 1999 11:24 PM
Subject: Enough with the "if" argument - Csound is *supposed* to be ancient!


>C'mon, guys, quit arguing for a radical change in syntax. Csound is
>csound. There are plenty of other options available if you want a more
>modern synthesis environment.
>
>Csound is after all, the evolution of the very ancient MUSIC xx
>packages, and I beleive that although it is current written in C, it was
>at one point translated from assembler.
>
>I can't help thinking, that if you are looking to redefine the orch
>language, than why bother keeping the Csound engine at all? With all the
>work you would have to go through to do this, you might as well use a
>different synth engine, one that would be much faster than the Csound
>approach.
>
>Remember folks, the Csound orchestra isn't even compiled to either
>machine code or C code, it is essentially put into a linked list of
>pre-compiled functions that is traversed at run-time. Hence, it's
>probably similar to a byte-code compiler in terms of performance. And on
>top of that, there's the K-rate problem - for many things you need
>k-rate == a-rate, but if you do that, you still have the overhead of
>calling all those unit generator functions that will in turn set up
>their k-rate loops, which, for all that overhead, you will make only
>*one* pass through.
>
>Oops, I was starting to rant there, wasn't I? Sorry. But the point is,
>Csound is Csound. It isn't particularly efficient, it's syntax is
>ancient, it's source code is spaghetti. So, sure you can start rewriting
>the parser, but if you're going to go through all that trouble, wouldn't
>it be better to explore other packages?
>
>Of course, the one advantage Csound has at the moment (and this counts
>for a lot!), is that however antique it is, it seems to have built a
>critical mass, and has by far the largest unit-generator collection than
>is available for, say, Common Lisp Music, or Perry Cook's toolkit. So
>much so that I've been thinking of loading the Csound syntax back into
>my Common Music image :-)
>
>Larry
>
>
>--  Larry Troxler --  lt@westnet.com  --  Patterson, NY USA  --
>