Tags in the .csd File

The system of separate .orc and .sco files was later supplanted by a single-file format with the filename extension .csd. Most Csound music written today is in the form of .csd files. A .csd file has a very specific structure, which is delineated by a few tags. These look like HTML markup tags, but they have nothing directly to do with HTML. The bare template for a .csd file looks like this:

  <CsoundSynthesizer>
  <CsOptions>
  </CsOptions>
  <CsInstruments>

  </CsInstruments>
  <CsScore>

  </CsScore>
  </CsoundSynthesizer>

In HTML markup, as here, tags are surrounded by angle brackets: < and >. Each section begins with a tag that has a special name and ends with a tag that has the same name preceded by a slash character (/). Sections can be embedded within other sections. Looking at this code, then, we can see that the outermost section is surrounded by <CsoundSynthesizer> tags. Within this are three subsections—<CsOptions>, <CsInstruments>, and <CsScore>, each of which has its own start and end tags.

Between the <CsInstruments> tags, you’ll create instruments. An instrument is basically just a chunk of code that carries out one well-defined task. It does something. (Usually it will generate audio signals, but it might do something else instead.) Between the <CsScore> tags, you’ll create an event list. Each event in the score will start an instrument and tell it to do whatever it does. The score may contain a few lines that do other things instead, as explained in Chapter 8, “Writing a Csound Score,” but if you think of the score as a list of instructions that you’re giving to Csound, telling it when to start a note on a given instrument and how long that note should last, you won’t go far wrong.

The relevance of Csound’s history may become apparent if you think about this structure for a moment. Within the <CsOptions> area, we can place whatever command-line flags we need (and also the name of the output file to write to disk). When we put the flags here, we don’t have to type them at the command line each time we want to run Csound. The <CsInstruments> section replaces the old .orc file and contains the instruments that will be used in the project. The <CsScore> section contains the same elements that would have been placed in a .sco file.

We can invoke Csound from the command line, as in the early days, and give it the name of a .csd file containing all the information it needs to run. (The older .orc/.sco file format can still be used as well.) More often, Csound users write their music in a front-end program. (See Chapter 9, “Front Ends,” for more on front ends.) Csound Power! was written using the CsoundQt front end, which is described in detail in Chapter 5, “Using the CsoundQt Interface.”

One of the many services that front ends generally provide is that they replace the command-line flags with settings in a dialog box. The functionality of such a dialog box will be largely or entirely the same as the functionality of a set of command-line flags, but modern computer users are more accustomed to dialog boxes.

Because CsoundQt has a Configuration dialog box, the <CsOptions> section of the .csd files can normally be left blank. In fact, these tags can be omitted altogether if there’s nothing between them. You can do all of your work in the other two areas, creating instruments in the <CsInstruments> section and score events in the <CsScore> section.

If you open, in a normal text editor, a .csd file that was created in CsoundQt, you’ll see some other tags, including things like <MacOptions>, <MacGUI>, <bsbPanel>, and <EventPanel>. These sections contain code generated by CsoundQt for its own internal use. Normally this code is hidden from the user by CsoundQt, and it shouldn’t interfere with Csound’s operation if you invoke the .csd from the command line. In the next chapter, we’ll look at the features of CsoundQt that these elements control.