Precisely for this reason, there are brief but real compositions in the csound/examples directory.

Probably the best way to smooth the path for beginners to Csound is to improve the quality of these examples. More "Wow!" factor, in other words.

It would also be useful to make the examples easier to change and adapt, with comments as to what parts can most fruitfully be changed.

Regards,
Mike


-----Original Message-----
>From: Robert or Gretchen Foose 
>Sent: Mar 24, 2008 10:50 PM
>To: csound@lists.bath.ac.uk
>Subject: [Csnd] Remarks on recent Archive and Documentation discussions
>
>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
>
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"