You may wish to use, or to examine, Silence, a system for algorithmic
composition that uses Csound for synthesis
(http://www.pipeline.com/~gogins). Silence stores all score data in memory
in the form of a "music graph," a tree of nodes (elements of music). Nodes
can be individual notes, groups of notes, score generating processes,
transformations of notes, random variables, and more, including direct
operations on pitch-class sets.

Silence stores its files as Extensible Markup Language (XML), that is to
say, hierarchically organized, tagged text files. If you do not use Silence
you may still wish to experiment with XML or other ways of hierarchically
tagging text. This can be as simple as


i 1 2 3 4 5

i 1 2 3 4 5
i 2 2 3 4 5
i 3 3 3 4 8



Using XML theoretically permits one to include all the elements of a piece
(including the Csound orchestra file, audio samples, etc.) in one nested
file. The Csound "csd" file is one example of such a use of XML.

I too tried the database method, but the hierarchical representation is a
better fit to the composer's procedures, and a modern PC has more than
enough memory for the biggest score plus all the things you want to do to
it; the database method is much slower for the tens to hundreds of thousands
of events in a big piece.

If you don't want to mess with Silence, or to write your own tree manager,
then use a Midi sequence or notation software, export sequences, and render
them with Csound. Good sequencers now support some of the same hierarchical
modeling (looping, etc.) that Silence does. You can write Csound instruments
to use Midi sequences directly, or you can translate the Midi sequences into
regular Csound scores first (Silence will do that also).


-----Original Message-----
From: Tobiah 
To: Csound List 
Date: Wednesday, June 02, 1999 12:25 PM
Subject: What? Not another environment variable!


>
>I have been thinking about managing score data.  I have
>been toying around with using an SQL database to house the
>data in.  I thought that it would be a good idea, because
>it would allow different score generation programs from
>different segments or tracks of a piece to easily examine
>and depend on previously generated segments.
>
>After writing the surrounding data I/O routines for a
>simple notelist database model, I decided that the task
>may not benefit from the services of the database engine
>to the degree that other bodies of data do.  There is
>really only one way to write a note for Csound, and there
>is not much else to be done on the acquisition side other
>than to grab a given list of notes, and process them in
>some way in main memory.
>
>The ever comfortable text file again (happily) took it's
>throne in my mind as the best method of storage for score
>data.  Now I have only to find a way to embellish my methods
>for reading and organizing score data in order to claim
>the benefits that I envisioned would come from the database
>server.
>
>I tend to use a Csound score as part of the *synthesis*
>rather than for just an event scheduler.  Often it is
>difficult to decide which is happening, when events
>exhibit a periodicity of say, 10 per second.  The scores
>can become very large.  They are sometimes more akin to
>soundfiles in that they are very large lists of floating
>point data.  Convolve or pvoc analysis files would be
>counterparts.  A common occurrence is for one program to
>read in a score file generated by another, and to process
>or respond to that data in some way in order to write it's
>own score for its own sound module.
>
>For sound files, and analysis data there are special
>directories sought through when they are required.  SADIR,
>and so forth.  This is immensely useful when a set of
>pieces is maintained over the course of a long time, and
>across different physical drives or machines. It allows
>many pieces to easily share libraries of input sound files,
>and allows one to keep these large files out of the way
>so that the programs that generate the sound can be backed
>up, and multiple revisions of them can be maintained without
>having to worry about disk space.
>
>I am proposing a similar convention for score data.  If
>my score generation programs knew where to look for a score
>with a given name regardless of how the hierarchy of my
>piece's directory structure may have changed, then I could
>avoid much tedious maintenance editing as my piece moves
>from shapeless to complex and interdependent amongst itself.
>
>I also propose a new standard location for orchestras,
>(after the current directory of course) only because it
>would be very handy for maintaining a library of instruments
>to be #included from the main orc.
>
>How about:
>
>        $SCODIR - The alternate score search path
>        $ORCDIR - The alternate orchestra search path
>
>Toby