Hi, 

I have been working off and on now for several months on trying to make
Cscore standalone programs work on OS 9.  I have corrected several
compilation issues and a few bugs in the Cscore code.  However, I still have
some questions.

I get memory access errors when running Cscore programs with certain scores.
The manual says "An event in Cscore is equivalent to one statement of a
standard numeric score or time-warped score."  Does 'standard numeric score'
mean that you cannot use any of the shortcut notations like '.', '>',
expressions, etc.  My Cscore programs seem to crash or give erroneous
results when I do use these notations.  The manual also states "As stated
above, the input files to Cscore may be in original or time-warped and
pre-sorted form;" and the section which describes all of the shortcuts is
labeled "The Standard Numeric Score," so I hope that you can see why I am
confused.

Also, does Cscore behave differently if used as a standalone as opposed to
being compiled into Csound?  In other words, it seems that a score gets
fully pre-processed by Carry, Tempo, and Sort by Csound before cscore() is
called, but this is not the case with a standalone cscore program.

Next, I guess that I am wondering what the future of Cscore will be in
Csound 5?  The code is still in CVS, but there has been a "push" to move
this type of functionality into clients of the API.  I could see several
possibilities.

1.  Just keep things the way they are.  Cscore programs can be run
independently or compiled into Csound and triggered by the -C option.

2.  Expect host applications to perform any score processing before calling
Csound.

3.  Create an API that would give hosts access to Csound's score reading
functions so that multiple code does not have to be maintained for this
function (or have a separate libsread?).  Perhaps, even have API functions
for passing score events to the host to be processed during performance?

4.  Since compiling cscore() routines into Csound is inconvenient (but may
offer more flexibility for input score format?), we could extend the plugin
concept to cscore programs and score generators.

This last idea is the most interesting to me, although I see no reason why
we couldn't do two or more of the above options.

Cscore plugins would just be shared libraries that export a single function
void cscore(void).  They would be loaded by a CL option such as
--cscorelib=mycscore and the cscore() function in the library would be
called instead of Csound's internal cscore() function.  I see no reason that
such a plugin couldn't be a score generator instead of a score processor
either, just ignoring the input score.

Additionally, it might be really usefulto be able to pass parameters to a
cscore plugin via special score events in the input score.  Matt Ingalls'
score generator in the Mac front-end takes parameters from special p- and
P-statements that can be mixed with ordinary score events.  In addition, it
allows these statements to occur after the score's e-statement and before a
final E-statement which signifies the end of the score to the score
generator.

I think it would be great to adopt these conventions (or extensions of them)
as standards for all cscore processors.  Perhaps all uppercase letters
should be allowed as score processor statements with 'E' being reserved to
indicate the end.  Csound's score reading functions should be modified to
not report these as errors and its performance routines should ignore them.

Anthony Kozar
anthony.kozar@utoledo.edu