Are you a Csound developer in SourceForge CVS? If not, why not?

Original Message:
-----------------
From: Anthony Kozar anthony.kozar@utoledo.edu
Date: Wed, 31 Mar 2004 12:13:57 -0500
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:4429] Re: Cscore questions and thoughts


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.


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .