|
This page is intended to be a guide to help those new to Csound choose the appropriate
version(s) for there purposes, install it(them), and tweak their systems to use Csound
effectively. This is not actually a difficult process, but there are a few tricks
that can improve the efficency in which you use Csound and keep your Csound projects
better organized.
I personally tend not to use Csound front ends. The invention of Csound Uniform
Files as made organization of my Csound projects a breeze, and I find a text editor more
than sufficient for most of my orchestra/score editing purposes. Still, there are
some excellent front ends for Csound and Win9x/NT, and I refer everyone to the MIT Csound homepage.
Any questions or problems with the material on this page can be e-mailed to Christopher Neese.
Obviously the first step in setting up Csound to run on a Win9x/NT PC is to download
the appropriate files. Currently, there are five important versions of Csound for
PC. (See Csound Flavors for a more detailed
discussion.) I have used all five versions, and can testify that each has its
strengths and weaknesses. It is important to note that all modern versions of Csound
for Win9x/NT support real-time audio and MIDI-file input.
If you are new to Csound, you should download the Csound manual immediately after
obtaining the executables. The Csound manual is available in several forms.
Simply choose your favorite form:
The PDF manual is probably the best for printing. It is designed so that when
updates are made, one needs only to print the updated pages. The Csound help file is
actually included with the Winsound distribution.
There are no installation programs for any of the Win9x/NT versions of Csound.
All you need to do is extract the files from their zip archive(s). To use AXCsound,
you must register its ActiveX component. This is done by typing something like:
C:\WINDOWS\SYSTEM\REGSRV32 C:\CSOUND\AXCSOUND\JCSOUND\JCSOUND_CSOUND.DLL
This is done at a command prompt or using the Run Dialog Box. You will have to
edit the above command so that the directories are correct, of course. The JCSound_Csound.dll
file can be moved as desired even after it is registered. You can probably even
delete it, based on my experience.
The big question is where to put all the files, especially if you use more than one
Csound. You are most likely going to want to have a directory labeled Csound
somewhere. But if you just dump everything into this directory, things might get
kind of crowded, especially if you use several versions of Csound. On the other hand
having a separate directory for each version of Csound you use isn't necessary either.
Consound is designed to be used from the command line.
The only file that is really important is Csound.exe. Keep this
file in the Csound directory, and move the other files, which are simply readme
files, to Csound\Info or delete them.
DirectCsound is also designed to be used from the command
line. The only file that is really important for this version is Csound.exe.
The only problem is that Consound's executable is also called Csound.exe.
I recommend renaming the DirectCsound executable to DCsound.exe, and
keeping it in the Csound folder as well. The other files in the
DirectCsound distribution are just readme files and examples and can be kept anywhere, or
deleted. I keep them in Csound\DCsound, so that the Csound
directory stays clutter free.
Winsound and AXCsound are a different matter. They
aren't really intended much for command line use, although Winsound works exactly as
Consound off the command line. Since Open dialog boxes tend to look for files in the
current directory first, I like to keep Winsound.exe, and Csound.hlp
in the Csound directory, and keep my Csound pieces in nearby directories.
Move the other files, which are simply readme files, to Csound\Info or
delete them.
Extract the contents of the AXCsound distribution to an Csound\AXCsound
directory. This distribution is large, as it contains code and examples in addition
to the executables. You really don't want these files to get mixed up with the rest
of your Csound files. After extraction, move or copy AXCsound.exe to the Csound
directory.
Now that all of the executables are in one place, you are ready to work. To use
Consound or DirectCsound, simply open a Command Prompt and cd to the Csound
directory. (Then type something like Csound blah.orc blah.sco) To
use Winsound or AXCsound, you simply double click the executable icon from Windows
Explorer. At this point, you are ready to start following tutorials included with
the manuals. Note that it is normal for files such as Csound.gid and score.srt
to appear in any directory you use Csound. Csound.gid is a settings file
for Winsound.exe and should be kept with Winsound.exe. Score.srt
is just a sorted copy of the most recently rendered score file. Feel free to open it
in a text editor, delete it, or leave it alone.
It is unnecessary to edit any system files to use Csound on a Win9x/NT machine.
However, there are some useful configurations that can be made.
First, if you want to be able to type Csound blah.orc blah.sco from any
directory, you need to modify your PATH, to include the Csound directory.
To do this add the following line to the very end of AUTOEXEC.BAT
using a text editor or SYSEDIT:
PATH %path%;C:\CSOUND
 | I have a directory sys\misc in which I place useful console executables.
This is where I personally keep Csound.exe and DCsound.exe,
as well as Zip.exe, Unzip.exe, and several other executables and
batch files. This directory is one of the few directories in my PATH.
(Limiting the number of directories in you path reduces the problem of naming
conflicts.) I do this rather than add the Csound directory to my PATH,
since my Csound folder contains files that don't need to be in a PATH
directory. |
Even if you don't this, you can always type something like C:\Csound\Csound
blah.orc blah.sco
Next, you may find it useful to define some environment variables. There are five
environment variables that effect all Win9x/NT versions of Csound. They are: SFDIR,
SSDIR, SADIR, SFOUTYP, and CSNOSTOP.
| Variable |
Description |
Recommendation |
| SFDIR |
Soundfiles being written are placed in SFDIR (if it exists), else the
current directory. |
Don't set. It is better to always have output written to the
current directory. |
| SSDIR |
Soundfiles for reading are sought in the current directory, then SSDIR,
then SFDIR. |
Set to something like C:\Csound\sounds
This way, soundfiles you use a lot with Csound can be kept in a central location. |
| SADIR |
Analysis control files for reading are sought in the current directory,
then SADIR. |
Set to something like C:\Csound\analysis
This way, analysis control files you use a lot with Csound can be kept in a central
location. |
| SFOUTYP |
In the John Fitch Bath Csound version there is a pause before and after
each graph. This can be turned off if the environment variable CSNOSTOP is set to YES |
Don't set, unless this feature bothers you. |
| CSNOSTOP |
Csound produces WAV sound files when the -W command line flag is set or
when SFOUTYP is set to WAV. |
Set to WAV, since wav files are the standard on Win9x/NT platforms.
If you don't want to write wave files by default, then don't set this variable. |
To set the above variables as recommended, add the following lines to your AUTOEXEC.BAT
using a text editor or SYSEDIT, noting that the "/" character
must be used in place of the "\" character:
SET SSDIR=C:/Csound/Sounds
SET SADIR=C:/Csound/Analysis
SET SFOUTYP=WAV
| The default memory space for environment variable's is only 64 characters for
Win9x. If you define SFDIR, SSDIR, SADIR,
you will probably use 75% or more of this 64 characters. Thus, you may want to add
the following line to your CONFIG.SYS file using a text editor or SYSEDIT:
SHELL=C:\WINDOWS\COMMAND.COM /E:1024 /P
If a SHELL line already exists, simply add or modify the /E:1024
switch. This will increase the environment space from 64 characters to 1024
characters. Do not do this if you are using NT. |
If you change your AUTOEXEC.BAT or CONFIG.SYS files, you need to
reboot before these changes will take effect.
Csound orchestra, score, and uniform files are simply text files, and thus should be
edited with notepad. Some people may try to use Word or WordPad instead, but this is
risky as any formatting that accidentally creeps into Csound files will wreak havoc upon
rendering. Some of you may be wondering what is wrong with the standard windows
notepad. There are two problems. First, notepad cannot deal with files larger
than 64k. This is a 16-bit hangover (64k = 216) that strangely seems to
persist from windows version to windows version. I understand SimpleText has the
same problem, so I suppose maybe Microsoft and Apple like to have text editors that edit
entirely in RAM. The other problem is that notepad is missing nifty features like
find and replace.
Everybody seems to like a different text editor, and freeware text editors are a dime a
dozen on the Internet. I suggest visiting Winfiles
or Tucows and finding a replacement for yourself, if
you haven't already done so.
Personally, I use EditPad by Jan Goyvaerts. EditPad is nice as it is
designed so that you can simply rename it notepad.exe and completely replace the original
notepad. On the other hand, EditPad is simple enough that this replacement is not a
major change. In addition, EditPad recognizes \n and \t in its find and replace
dialog as newline and tab characters, and EditPad has a configurable file filter, so the
program can be configured to search for Csound files by default. Finally, EditPad is
nice because it is postcardware.
Others find that more intensive editors, i. e. emacs, are to their
preference. To each his or her own.
I recommend associating orc, sco, and csd files with your text editor. This makes
sense for orc and sco files, since they cannot be rendered alone. However, you may
prefer to associate csd files with either Winsound, Consound, or DirectCsound. This
is fine, but I will show you how to make secondary associations, which are available from
the context menu opened by right-clicking a file. So If you prefer, you can make
opening a csd file in a text editor a secondary association.
*Under construction*
*Under construction*
| Winsound is
the canonical version of Csound compiled for Win9x/NT. The canonical Csound sources
are maintained by John Fitch and have the
advantage of maximum cross-platform compatibility. In addition, Winsound adds an
easy-to- use dialog-based interface to Csound. However, Winsound's dialogs are also
its downfall, as a significant amount of computing time is lost maintaining the graphics
interface. Winsound often becomes unresponsive to keyboard and mouse events during
rendering, which makes it difficult to abort rendering. (Winsound is generally not
unstable however; it will always regain responsiveness after rendering is complete.)
Winsound's cons should be improved eventually, as it is multi-threaded so that rendering
and windowing occur in separate threads. |
| Consound is
the canonical version of Csound compiled for Win9x/NT as a console
application. The canonical Csound sources are maintained by John Fitch and have the advantage of maximum
cross-platform compatibility. Consound is the complement to Winsound; it lacks a
dialog-based interface, but gains processing power by not maintaining a graphics overhead,
the downside is that Consound is ASCII-only. Typically I render with Consound, using
Winsound when I need graphics for trouble-shooting purposes. |
| DirectCsound
is maintained by Gabriel Maldonado. This version is excellent, as it allows use of
DirectSound to virtually eliminate audio latency. In
addition, DirectCsound provides real-time MIDI support that is unavailable (or
non-functional) in the canonical versions, as well as some additional opcodes. I
believe real-time MIDI support may be included in the canonical Win9x/NT versions soon, as
all of the pertinent opcodes are already implemented. Like Consound, DirectCsound is
an ASCII-only console application. DirectCsound
also has the slight disadvantage of being slightly behind the canonical version, although
Maldonado does an excellent job of keeping DirectCsound concurrent with canonical Csound.
Finally, DirectCsound does not support DirectSound audio input, so signal
processing is still subject to audio latency. |
| AXCsound and JCsound are maintained by Michael Gogins. Together they form one
entity existing in three forms as described by Michael
Gogins:
 | As a standalone Windows software synthesizer, which can be played in real time by a MIDI
controller, used to render MIDI sequence files, or used to render Csound scores. |
| As an ActiveX control, which can be plugged in as a software synthesis component in
other software, like algorithmic composition programs. It is easy, for example, to adapt
public-domain fractal generating programs written in Visual Basic or Visual C++ to become
algorithmic composition programs that use AXCsound as a synthesizer. |
| As a Java package, JCsound, which can be plugged into Java software just as AXCsound can
be plugged into Visual Basic. I use JCsound as the software synthesizer in Silence, my
Java algorithmic composition system. |
AXCsound uses DirectCsound as its code source, so it shares a lot in common in with
DirectCsound. The ActiveX and Java aspects are what make this version special, and
for those familiar with these technologies AXCsound and JCsound are a must see. As a
standalone version of Csound, AXCsound doesn't add much beyond the canonical versions or
DirectCsound, however. If you prefer DirectCsound to the canonical versions, you may
want to use AXCsound as a dialog-based version of DirectCsound.
|
| Extended Csound or XTCsound is the result of collaboration
between Barry Vercoe the original
author of Csound and Analog Devices. As an
aside, Barry Vercoe's son Scotty
Vercoe is in charge of this project, an is an Oberlin
Conservatory TIMARA graduate.
XTCsound really isn't a Win9x/NT version of Csound, but rather a version of Csound that
runs on a Analog Devices SHARC DSP chip. Currently for $1000 one can obtain a
XTCsound development kit for Win95 (only). The kit includes XTCsound development
software and a card with the Analog Devices chip on it that sports MIDI In/Out, 4 channels
of analog/digital audio input, and 6 channels of analog/digital output.
The idea is that some manufacturer will be interested in developing a Csound keyboard or
Csound sound-card using Extended Csound. A stand-alone Csound keyboard is indeed an
intriguing idea but I don't know if Csound based soundcards have much of future. The
fact is DirectCsound on a modern PC is more powerful than XTCsound on the analog card.
In addition, Extended Csound is significantly different from the
canonical or "public" version. The syntax is the same for both versions,
but the opcode base of public Csound has diverged rapidly over the past two years from
XTCsound which is still at version 1.0 beta. In addition, there is no intent to keep
these versions synchronized at all.
The card does provide some functionality not supported by any Win9x/NT version of Public
Csound. First, XTCsound is free of the audio latency
problem, as all Csound code is executed on the card and has a direct connection to all
audio inputs and outputs. DirectCsound and AXCsound which also overcome the audio latency problem only do so for up to two channels of
output. thus the card is useful for real-time periphonic audio and latency-free
input allows the card to be used for signal processing. |
Definitions
- Audio latency
- Audio latency is a problem inherent in the traditional multimedia engines of most
operating systems. Basically, traditional engines do not provide applications direct
paths to the audio devices, thus there is delay necessitated by the "operating system
middleman". DirectSound, a component of DirectX, lowers audio latency by
providing application with direct control of audio devices.
Without DirectSound, an audio event may occur 100 ms (100 milliseconds or 0.1 seconds) or
more after the physical event that triggers it. A delay of more than 50 ms is
perceptible, and annoying to most performers. A delay of more than 50 ms is
particularly noticeable in signal-processing an acoustic source, as the delay creates a
double attack.
Audio latency is primarily a function of buffer length. More specifically, it is
given by
Delay = (Number of Buffers) * (Buffer Size) / ((Sample
Size) * (Number of Channels) * (Sampling Rate))
where Buffer Size and Sample Size have the same units, i. e. bits or bytes.
Buffer Size corresponds to Csound's -b flag, and Number of Buffers corresponds to the -+p
flag of DirectCsound (and is fixed for canonical Csound). Using DirectX can allow
one to reduce Buffer Size by an order of 4 or more. This decrease generally allows
sub-50-ms latencies and, in the words of Maldonado, "a more interactive performing
experience"
- Console application
- A Win9x/NT console application is similar to a MS-DOS application, except that it is
32-bit and had access to all of the Windows API's. Thus, Consound, a console
application, can provide real-time audio via the windows multimedia engine.
Real-time audio is not feasible in MS-DOS.
|
