I've been looking at csound and its alternatives (supercollider and
nyquist seem to be the most viable) with a goal of both making music
and applying my programming skills to an open source synthesis
project.  I've been following this conversation with interest, as it
touches on many of the topics I've been thinking about myself.

First off, I really like csound.  I first heard synthesized music when
I was a kid in the early 70s, and I never dreamed that I'd actually be
able to use a system very like the system that many of those pioneers
used to create those fabulous sounds.  There's a real sense of history
and continuity, and it's wonderful.

But, now in 2007, the ORC and SCO languages are, well, relics.  You
can almost see the punch cards in your hands as you look at them.  For
someone with a programming background, they just seem completely
lacking by modern standards.  And for novice programmers--meaning just
about everyone coming from the music side--they must be fairly
impenetrable.  It pains me to think of musicians getting together in
study groups to figure out things like how to hack up a portamento
mechanism for an instrument, or having to trudge through chapters of
the csound book devoted to needless mysteries.

The model of i-, k-, and a-rate variables was quite confusing for me.
The underlying interface that they abstract actually seems more
straightforward (initialize at the beginning, then every k period push
some control parameters in and get one frame of audio data out).  [cf
generators in Python 2.5]

I know that there are tools to generate SCO files (and maybe some
ORC?) from other sources, but I think that there are some problems
that prevent this from really being a suitable solution.  A principle
one for me is the "portamento problem": Roughly, I want to be able to
control the parameters (frequency, for example) of a "note" while it's
playing, from the "score" file, in a natural way and without having to
specially prepare the instrument.  As far as I can tell, this simply
isn't possible currently in cscore.

The current regime requires csound to support its own internal
programming language.  It seems like it would be much better to
offload that effort by using an existing language (that is already
being maintained by others elsewhere).  I'd choose Python, because I
like it and because it is designed and suitable for novice
programmers, but there are several other languages that would work.
With the right interfaces, perhaps many languages could be used
simultaneously, and I would prefer this more catholic approach.

It's less clear to me how score files should work.  On the one hand,
it's easy to see them as "data", similar to the current SCO files, or
HTML, etc.  On the other hand, there are many kinds of things I'd like
to do that'd be more "programmatic".  Without some programmability,
one immediately runs across the problem of wanting to repeat a
pattern, perhaps with small variations, which a pure data
representation will not handle.  The best thought I have so far is
that probably both approaches should be supported--a pure data
representation and a good programmatic interface.

If I was going to attempt this myself, I'd be inclined to pretty much
rip the head off of csound, keep the fabulously useful set of opcodes,
perhaps clean up the opcode interface, and redo the outer engine,
probably in Python plus C or C++, and maybe even try to see if Numpy
(Python numeric package) could help.

With proper design, perhaps you could get some parallelism almost for
free.  It'd be very nice to be able to run multiple processes on a
multicore box or on a pile of PCs.  (I'm not a fan of threads.)

A primary goal of doing this would be to make it easier to use and
extend csound.  In the end, I suspect most of us want to spend our
limited time on the music end, rather than futzing around with the
technical details.

I have more thoughts, but that's enough for one post.  I don't mean
this to sound presumptuous--please think of it as a set of ideas from
a "focus group" session with one of your fans.

Regards,
Mike

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net