Csound is not your average environment for producing electronic music. It requires a completely new approach to composition. It can help you get out of a rut, or at times be so frustrating that nothing productive comes out of a night's work. In this article I will explore some of the advantages and disadvantages of composing with Csound, go through some common mistakes, and list some tips for working more efficiently with the program. Keep in mind, some specific examples refer primarily to non-real-time Csound for Macs, but most of the principles discussed apply to Csound on any platform. Also, a good number of the ideas presented are just common sense and good file management. They may seem simple, but I would have been saved a lot of trouble if I had known these things when I started working with Csound.
One of the appealing factors of Csound is its portability. When working only with orchestra and score files, file size is extremely small. An average completed orchestra and score file combined is between 10K and 30K, while individual instrument files are usually smaller than 10K. All that is needed in this case is a floppy disk, making backup fast and inexpensive. Storage depends on the size of the sample library needed for that particular project when working with sample processing instruments. When working with the phase vocoder or other forms of analysis based synthesis (convolution, LPC, etc.,) it becomes convenient to save analysis files in order to stay consistent, making storage an issue. Analysis files can range from smaller than 10K to over 20MB, depending on the size of the file analyzed. I have found removable media such as 1MB Jaz disks and CD-R's to be adequate. The fact that large capacity drives are quite common and relatively affordable to most desktop musicians makes this almost irrelevant.
With Csound it is quite easy to start producing very unique textures. The "no limits" nature of Csound allows the user to easily surpass sounds possible with commercial synthesizers. (Of course, Csound only sounds as smart as its user.) By allowing the user complete control over the smallest details, one is no longer bound by the hardware limitations of a commercial synth. A large area of opportunity for generating new and unusual sounds exists in Csound's powerful sample processing functions. The phase vocoder, convolution, and granular processing are quite accessible and implemented very well. The tradeoff of the user friendliness of graphic based software for the quality of Csound produced audio makes taking the time to become familiar with Csound worth it.
The Learning Curve
I wonít lie about this, Csound is difficult to pick up. For those of us with no programming background, working strictly from text files can be quite frustrating sometimes, or at least take time to get comfortable working in the environment. Debugging instruments can be tiresome, but I will give some tips on avoiding this task later on in the article. There is an initial hump the user must get over. I cannot tell you how long it will take, but you will know when you get there, and by following some of the guidelines presented in this article (even if you discover they are not right for you,) a level of comfort will be reached and you will develop your personal style. Be patient, it may not come right away.
Csound is free. With a number of high quality online resources (cSounds.com, The Csound FrontPage @ MIT Press, The Csound Ezine, the Csound Mailing List) learning materials are easy to come by as well. Through these sites, (listed at the end of the article,) you will find numerous links to instructions for getting and installing Csound, tutorials, instrument examples, and many other resources. As I mentioned earlier, storage is also relatively cheap.
Csound can be computationally intensive at times. Rendering large files requires patience. Macintosh G3s and G4s can process frequency domain techniques such as FM and additive relatively fast. The size of your score will affect this though, so take that into account. Sample processing and analysis based techniques require more processing time and can take much longer. The phase vocoder is a perfect example. Producing short sounds under thirty seconds can take an hour or more to render at a high resolution (using sr = 44100 and kr = 44100) or when using analysis files with large bands.
A very common beginnerís mistake to not have set your Default Directories. It is a good idea to keep your sound samples and analysis files in their own respective folders. Dump all the samples you want to use in Csound instruments into a folder, then select that folder as the Sound Sample Directory, then do the same for analysis files.
Make sure variables are set at legal rates. Some opcode arguments can only be i rate, others can be k or a rate, some, all three. Below is an opcode with its arguments copied from The Csound Manual.
ar oscil xamp, xcps, ifn[, iphs]
With oscil, the first two arguments may be i, k, or a rate variables, while the third and fourth can only be i rate variables. Keep the manual handy for little details like this.
Any conflict within the header or between the header and an instrument will break your file. Remember, ksmps = sr/kr, and make sure that nchnls matches the number of channels in your instruments. Below is a typical orchestra header.
sr = 44100 kr = 4410 ksmps = 10 nchnls = 2
Variables must be assigned before they can be used as an argument. This is an easy mistake to catch (your GUI will probably tell you where this problem is,) but it still happens so it makes the list. Below is a correct example of assigning variables.
Kamp = p4 ;amplitude value shows up in fourth p-field Kcps = p5 ;cycles/sec value shows up in fifth p-field Ifn = 1 ;uses f-table 1 as waveform Iphs = 0 ;optional phase argument is set to zero ar oscil kamp, kcps, ifn, iphs
As with anything, working with Csound takes practice. If a session starts to take a turn for the worst, take a break, or maybe it is a sign to call it a night. Also, do not try and take on too much at once. Learning Csound code is very similar to learning a new language, too many new vocabulary words and you will overload. Repetition will make you more familiar with the syntax and you will start to discover what works best for you.
Keep your orchestra and score files neat. There are more important things you can be doing than counting p-fields. Keeping columns aligned and labeling will make reading your instruments easier on you tomorrow. It takes extra time, but give parameters names that make sense. Attack can be iatk, decay- idec, an output signal-asig, and so on. Your instruments will make more sense and this will help you remember parameter lists easier. Using a simple orchestra containing simple oscil and foscil instruments, here is an example of a format that will be difficult to read.
instr 1 a1 oscil p4, p5, p6, p7 out a1 endin instr 2 a2 foscil p4, p5, p6, p7, p8, p9, p10 out a2 endin
These might be easier to read if laid out like this:
instr 1 ;oscil, single oscillator instrument kamp = p4 kcps = p5 ifn = p6 iphs = p7 asig1 oscil kamp, kcps, ifn, iphs outs asig1, asig1 endin instr 2 ;foscil, two operator FM instrument kamp = p4 ;amplitude kcps = p5 ;cycles per second kcar = p6 ;carrier kmod = p7 ;modulator kndx = p8 ;modulation index ifn = p9 ;function table used for car and mod iphs = p10 ;phase asig2 foscil kamp, kcps, kcar, kmod, kndx, ifn, iphs ;FM opcode w/ arguments outs asig2, asig2 ;stereo output signal endin
This example is a little exaggerated, not every parameter needs a name, p-field, and a comment. In fact, this will likely make real-time Csounders cringe, but initializing instrument arguments with more meaningful labels will make your orchestras easier to read and debug and will not affect rendering to disk (you can spare the extra time it takes to initialize.) Also, comment frequently in your instruments. When you come back to a project tomorrow, next week, or even next year, you may not remember what igpos stands for, so take advantage of your semicolons and comment, comment, comment. Below is an example of a score format that can be a real mess if used with large score files, or even as the score file for simple oscil and foscil instruments.
f 1 0 4096 10 1 i1 0 5 30000 440 1 0 i2 0 10 26000 1000 2 1 1 1 0 e
Imagine using this format for a score that contains many note events and even more instruments. What happens if you decide to expand your instrument by adding several p-fields? If you are like me, it will not make much sense when you come back to the file a few days later. Perhaps a more sensible way to format this example would be like this:
;FUNCTION 1 USES THE GEN10 SUBROUTINE TO COMPUTE A SINE WAVE f 1 0 4096 10 1 ;OSCIL ;p1 p2 p3 p4 p5 p6 p7 ;in st dur amp cps fn phs i1 0 5 30000 440 1 0 ;FOSCIL ;p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 ;in st dur amp cps car mod indx fn phs i2 0 10 26000 1000 2 1 1 1 0 e
Again, it may seem a bit excessive for just a few lines of a score, but when you use this format to create much larger score files, you will be able to write and edit much faster, rather than having to count columns. Keep in mind that Csound ignores excess white space, so tabs and extra spacing between p-fields are perfectly legal. Your files will soon develop a look that you are used to and can make sense of quickly.
Obviously, but I have to say it. In order to re-render an instrument, you must save the text file you have changed. Before making drastic changes, make sure you "Save as..." under a new name. If the changes did not work out, simply open the backup file. Also, when using the Csound PPC front end, unless you change the name of the output file when re-rendering, Perf will overwrite the existing sound file. You may have already rendered the perfect file and not realized it until you heard how bad the new instrument sounds. This brings up the larger issue of file management. It is not practical to save every version of an instrument you make. You will know when you are getting close to something worth keeping, use your judgment.
Test, test, and test again
One way to avoid debugging in the future is to constantly test your instruments. When making small changes such as adding an envelope, render the file to make sure it works. That way, when the instrument breaks, you do not have to dig through lines of code looking for that misplaced comma. Most front ends will tell you where an error is, but it is not always crystal clear. Constant testing will save you time in the long run and possibly save you from having to throw out entire instruments, and that hurts, believe me.
Copy and paste
Yet another way to avoid debugging. Copy and paste from instruments that work. Whether it is from your own library or a collection such as The Csound Catalog, this will save you time as well. I do not suggest typing out new instrument entirely. Even when working within an instrument, copy and paste as much as possible. Re-typing parameters wherever they occur is a good way to break an instrument. One typo can easily break an instrument and may not be so easy to find.
Start with what you know
The best way to get started with Csound is to begin with a topic you know. Are you a wiz with analog? Then build that Moog bass you know so well. You will learn a lot about Csound and even more about analog in the process. Even tweaking existing instruments will help familiarize you with the format, which takes care of another important factor when working with Csound, making sound. When starting out, it can take some time to make a sound, and even longer to make a satisfying sound. Modifying old instruments should help keep interest up and frustration down. Once you get over that first hurdle, the sounds will come faster and easier.
Get together with someone who knows Csound. Study their instruments, you can learn a great deal just by figuring out how another personís instruments flow. There are usually many ways to implement the same idea in Csound, you may find something useful. If there is no one around, join the Csound mailing list.
To Join the Csound Mailing List:
Send an e-mail to email@example.com
In the first line of the message, submit: subscribe csound
There is a large, supportive, and extremely knowledgeable community out there. Ask questions, but ask them right. Include code that is broken, what platform you are using, and list possible solutions you have already tried. So persist, stay organized, get involved, and most importantly, have fun. Happy Csounding.
Matthew Thieshttp://www.mp3.com/mjthies - Dark ambient and minimal music in Csound.
Sites to See
cSounds.com - http://www.csounds.com/
The Csound FrontPage @ MIT Press - http://mitpress.mit.edu/e-books/csound/frontpage.html
The Csound Ezine - http://www.csounds.com/ezine/
Mac Csound - http://music.columbia.edu/~matt/
Gabriel Maldonado Home Page - http://web.tiscalinet.it/G-Maldonado/home2.htm