| 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
|