Csound can be operated in a variety of modes and configurations. The original method for running Csound was as a console program (DOS prompt for Windows, Terminal for Mac OS X). This, of course, still works. Running csound without any arguments prints out a list of command-line options, which are more fully explained in the Command Line Flags (by Category) section. Normally, the user executes something like:
csound myfile.csd
or separate orchestra (orc) and score (sco) files can be used:
csound myorchestra.orc myscore.sco
You can find many .csd files in the examples folder. Most opcode entries in this manual also include simple .csd files showing the usage of the opcode.
There are also many Front-Ends which can be used to run csound. A Front-End is a graphical program that eases the process of running csound, and sometimes provides editing and composing functions.
Csound also has several ways of producing output. It can:
When Csound runs, it prints a text output to the console, which shows data about the Csound run. A Console output looks something like this:
time resolution is 0.455 ns
PortMIDI real time MIDI plugin for Csound
virtual_keyboard real time MIDI plugin for Csound
PortAudio real-time audio module for Csound
0dBFS level = 32768.0
Csound version 5.10 beta (float samples) Apr 19 2009
libsndfile-1.0.17
Reading options from $HOME/.csoundrc
UnifiedCSD: oscil.csd
STARTING FILE
Creating options
Creating orchestra
Creating score
orchname: /tmp/csound-XYACV6.orc
scorename: /tmp/csound-IYtLAJ.sco
rtaudio: ALSA module enabled
rtmidi: PortMIDI module enabled
orch compiler:
17 lines read
instr 1
Elapsed time at end of orchestra compile: real: 0.129s, CPU: 0.020s
sorting score ...
... done
Elapsed time at end of score sort: real: 0.130s, CPU: 0.020s
Csound version 5.10 beta (float samples) Apr 19 2009
displays suppressed
0dBFS level = 32768.0
orch now loaded
audio buffered in 256 sample-frame blocks
ALSA input: total buffer size: 1024, period size: 256
reading 1024-byte blks of shorts from adc (RAW)
ALSA output: total buffer size: 1024, period size: 256
writing 1024-byte blks of shorts to dac
SECTION 1:
ftable 1:
new alloc for instr 1:
B 0.000 .. 2.000 T 2.000 TT 2.000 M: 10000.0 10000.0
Score finished in csoundPerform().
inactive allocs returned to freespace
end of score. overall amps: 10000.0 10000.0
overall samples out of range: 0 0
0 errors in performance
Elapsed time at end of performance: real: 2.341s, CPU: 0.050s
345 1024-byte soundblks of shorts written to dac
Removing temporary file /tmp/csound-CoVcrm.srt ...
Removing temporary file /tmp/csound-IYtLAJ.sco ...
Removing temporary file /tmp/csound-XYACV6.orc ...
The console output of Csound is quite verbose, particularly before the actual performance (like version, plugins loaded, etc.). Performance actually started when the console printed:
SECTION 1:
In this particular run, the lines:
new alloc for instr 1: B 0.000 .. 2.000 T 2.000 TT 2.000 M: 10000.0 10000.0
Show that a single note for instrument 1, that lasted 2 seconds starting at time 0.000, was produced with an amplitude of 10000 for both channel 1 and 2. An important section of the console output is:
end of score. overall amps: 10000.0 10000.0
overall samples out of range: 0 0
Which shows the overall amplitude and the number of samples which were clipped because they were out of range.
The line:
Elapsed time at end of performance: real: 2.341s, CPU: 0.050s
Shows the clock time and the CPU time it takes for the processor to complete the task. If CPU time is lower than clock time it means the csd can run in realtime (unless it has some sections which are extremely CPU intensive). The "real time" figure is the total running time and it is larger because it acounts for disk access. module loading, etc. (CPU time is strictly number-crunching time). If you have a sound that lasts for 100s and it takes 5s to generate it offline, it means that you are taking around 5% of CPU, and that it runs on 0.05 of realtime.