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  --