| Hello all,
I don't think that anyone will disagree that csound is immense, both in
the ways it can be used and the tools that it provides for creating sound.
That said, I think many, if not all, of the people who first encounter
it are somewhat at a loss as to where to begin. Dr. B's 'toots', and
the others that can be found on csound.com are extremely helpful in
beginning to understand the language. However, it seems as though there
has been a tremendous increase in the number and type of opcodes and gen
routines available since they were written. The manual documents all of
them concisely, it's true. But perhaps an analogy will be helpful to
show my frustration with it.
Suppose you give a child a hammer, a box of nails, and two or three
short boards. You show him how to swing the hammer, you show him that
nails are sharp, and you show him that boards can lie flat, be placed on
edge, or on end. Using his imagination, the child may discover you can
hit the nail or the board with the hammer. He may figure out that you
can push the sharp end of the nail into the board (or the hammer
handle). But it may take him QUITE a while to figure out that he can
use the hammer and nails to fasten two of the boards into an 'X', nail
the third perpendicular to them, put another nail into the opposite end
of the third board and bend it, thus creating a free-standing coat
rack. Now imagine you've given that same child a COMPLETE set of
Craftsman handtools, and a large building full of boards, bricks, pipes,
wires, etc. How long will it take for him to figure out how to build a
house?
The toots are a start, like showing the child how to hold the hammer and
hit the nail. The reference manual is more like a set of building codes
and spec sheets. What I find lacking are the type of resource materials
you find at Lowes or Home Depot, that show you how to mix the concrete
for the footings, how to use a square to lay out your foundation and get
the proper pitch for your roof, and how to secure your frame to the
footings and build it strong enough to stand up to the wind, and,..
well, you get the idea. There are a few such resources available..like
Kim Cascone's article on Ambient Music, or the Mikelson articles in
Csound Magazine. The problem is that they're also old, and there are
too few of them.
Having .csd's of works to look at can be very useful, but not if they're
not 'self-documenting'. I may be able to see how something was done in
a .csd, but understanding why this approach was used, and what makes it
better than another is certainly not obvious from the 'raw code'. For
my own part, I think I own or have read every resource that is available
for csound, and I still feel frustrated by the tremendous leap that is
needed to get from the toots to understanding the .csd's of the really
'interesting music' that has been created with csound. More articles
like 'A Tour of Oscillators' in Csound Journal would be helpful,
covering things like the wealth of gen routines, envelope generators,
etc. (And please don't assume that all csound users are solidly grounded
in graduate level math and acoustics when you write them!)
Finally, every book I've ever read that teaches programming emphasizes
(ad nauseum) documenting your code. For csounders whose work may be
studied, this is absolutely imperative. For example I've recently been
trying to figure out a simple bass instrument (Rene Nyffegger's) that
uses a calculation result for an opcode's parameter. There are four
'oscil's and the calculation is used to divide and balance the signal
strength among them. It includes subtracting an apparently arbitrary
value from a 'percentage of a p-field' calculation. Why the subtraction
is necessary is beyond me..perhaps it's just a 'kludge' to fine tune the
sound. A simple inline comment would have made it clear. This is just
the most recent case of my being frustrated by raw code. And I know I'm
not alone here.
One final remark about .sco files. When I see a score with 12 or 17
p-fields and under most of them is one actual number which is carried
for three pages, it make me wonder why that parameter couldn't have be
coded into the .orc. If there are any changes, they could probably have
been handled by 'if-else' code, thus simplifying the score. Of course,
if you're using a spreadsheet to generate scores, using a 'fill' option
may be easier to get the result you want. But it does make it a little
harder for someone who is trying to figure out how your instrument is
working.
I guess I've said enough to generate some comments. Hopefully, some
articles, too. Having sounded off, I'll now sign off.
Bob Foose
|