I would strongly encourage you, and other Csound users and developers, to
give some real thought to how Csound should be used in the future, since in
Csound 5 we have a chance to add or change things. Such changes should be
musically motivated and well thought out with thorough discussion.

One thing I have thought is to add all the cscore functions to the Csound
API, which would mean that they would also be exposed via Python in
CsoundVST. This would enable score generators to skip generating a text sco
file or score section in a csd file. Not sure what this gains, actually;
Python is one of the most powerful languages there is, and generating text
sco, srt, or even csd files is dead simple already.

cscore was meant to be used by composers statically linking their custom
score generator in with Csound, so cscore could be changed from static
linkage to dynamic linkage. But I think this is not necessary since
composers up to running a C make for cscore can certainly manage to link in
libcsound.a.

It would be helpful if you could provide us with some "use cases," detailed
examples of typical uses that you envision for cscore, or for any other way
you would like to see scores generated or imported for Csound.

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "Anthony Kozar" 
To: "Csound Developers Discussion List" 
Sent: Tuesday, March 30, 2004 10:53 PM
Subject: [CSOUND-DEV:4424] Cscore questions and thoughts


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

On 3/31/04 8:24 AM, Michael Gogins etched in stone:

> I would strongly encourage you, and other Csound users and developers, to
> give some real thought to how Csound should be used in the future, since in
> Csound 5 we have a chance to add or change things. Such changes should be
> musically motivated and well thought out with thorough discussion.

Sure.  I think they should be well thought out as well.  I guess that I tend
to think more in terms of technical possibilities rather than musical
desirability.  So, I am open to any other implementation ideas.

> One thing I have thought is to add all the cscore functions to the Csound
> API, which would mean that they would also be exposed via Python in
> CsoundVST. This would enable score generators to skip generating a text sco
> file or score section in a csd file. Not sure what this gains, actually;

Well, I think one important gain of exposing part of Csound's score reading
functionality is that there will be one, standard implementation for doing
so, and only one set of functions to be maintained.  Right now, a host
application that wants to provide score manipulation features would use its
own code for reading and writing the score, which makes it prone to breaking
should things change in Csound.  Plus, why reinvent the wheel when Csound
already knows who to read a score and turn it into an easily usable data
structure?  (I think someone else suggested this awhile ago).

However, I am not sure that the Cscore functions are currently the best ones
to export.  From what I can tell, one seems to lose all of the conveniences
of the Carry preprocessing step, score expressions and macros, and probably
newer inventions like named instruments when using Cscore.  So, I think that
what is needed is either an API which uses Csound's score preprocessing or a
new "higher-level" API which allows scores containing these features to be
manipulated.  Perhaps Cscore can be updated to do this and become the
"standard API."

> Python is one of the most powerful languages there is, and generating text
> sco, srt, or even csd files is dead simple already.

Yes, I myself am really more interested in using a language which allows
rapid prototyping such as Lisp or possibly Python for composing.  But some
people really like doing everything in C for some reason.  In addition, I
think that, for example, providing a standard Python extension module for
interfacing with Csound's score functions could simplify the development of
score generators and processors for anyone who wants to work in Python.
Naturally, having a score manipulation API in C would ease the development
of similar libraries for any other language that can interface with C.

> cscore was meant to be used by composers statically linking their custom
> score generator in with Csound, so cscore could be changed from static
> linkage to dynamic linkage. But I think this is not necessary since
> composers up to running a C make for cscore can certainly manage to link in
> libcsound.a.

Well, my motivation for wanting Cscore plugins is that it is not really
convenient to statically link Cscore programs into Csound on the Mac right
now.  You end up with many different versions of the Perf application (the
Csound engine) littering your hard drive.  These variants are "bloated" when
you consider that they each use over 1MB in disk space while a shared
library containing just your cscore() function would only be a couple of KB.
In addition, because of the current mechanism by which Csound runs on the
Mac, you cannot choose which version of Perf is launched by the OS if you
have more than one on your hard drive.  So, you have to either delete all
but the one you currently need or somehow hide the others from the OS.

The problem will be somewhat alleviated by switching to using a Csound
shared library instead of Perf, which I hope to accomplish for the release
of Csound 5 (and Matt already is doing so for MacCsound).  But you would
still have to compile multiple versions of the CsoundLib and swap them in
and out of your host application's directory in order to use multiple Cscore
programs at different times.

I actually went ahead and prototyped the Cscore plugin idea last night
starting with the code in dl_opcodes.c from 4.23f11.  I now have several
different simple Cscore plugins and can choose to load one or not with a
command-line option.  It works rather nicely, and everything can coexist
within the same directory without causing any interference.

The other reason that I find dynamic linkage a more appealing option is due
to the way I tend to use Cscore.  I find Cscore more useful for simple
"tweaks" to my scores than for wholesale algorithmic composition.  For
example, I might think to myself "now how would this sound if all of the
durations were 5% shorter?"  Then after trying that I might think "what
about if they were 50% shorter instead?"  Or I might just want to transpose
a section of instrument 21 up by a perfect fifth.  Cscore is fairly easy to
use for these types of modifications.  And since I tend to want to
experiment with these operations, dynamic linkage for my cscore() programs
is easier.

> It would be helpful if you could provide us with some "use cases," detailed
> examples of typical uses that you envision for cscore, or for any other way
> you would like to see scores generated or imported for Csound.

I will try to come up with more thorough examples than the ones above.  As
for the other ideas I mentioned (quoted below), they were just some quick
suggestions for how Cscore programs could be made more interactive.
Currently there is no way to pass parameters to Cscore, so you have to
recompile to get a different result.  I really liked the way that Matt's old
score generator allowed its parameters to be embedded directly into a normal
score.  I thought the implementation was clean and easily adaptable to other
uses.  It also would be a piece of cake to integrate his style of "parameter
passing" into Csound's score reading functions since it uses the familiar
"letter followed by a list of numbers" format.

Here's an example from Matt's documentation (its meaning isn't important):

p0 1.5   3.0   457  5
p1 1     0 
p2 .25   0     1    .25  .5
p3 1     0     .25  .1   .01   1  3  5
P4 10000 30000 1    500  10000

Anthony Kozar
anthony.kozar@utoledo.edu


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