|
Hi Csounders,
This is my two cents responding most directly to Ricardo's recent input
but just joining the thread in general.
The parser code is Byzantine but the syntaxes (?) of correctly formed
csound programs and data are what csound is, so it stands. Most of the
"whatif"s are really asking "What if csound wasn't csound?". Well
then, it wouldn't be csound.
So there.
The score parser should be able to handle any .sco file as now defined
but I certainly don't agree it should be modified to handle, a la MinC
(i.e., Cmix) logical structures like looping and branching, etc. These
can easily and more flexibly be handled by preprocessors like Matt
Ingalls' score generator. I look at the csound syntax itself as a kind
of "assembly" or "low level" language for sound synthesis.
In order to achieve the program structures Ricardo said he would like
to see in the orchestras, it would probably be necessary to go to an
LALR parser using something generated by the Yecch-Lax family. These
are great tools but it wouldn't be csound anymore. There is no reason
that csound orchestra preprocessors can't be written with LALR parsers
to generate csound orchestras, of course, but being essentially
compilers, orchestra generators are a less common industry than score
generators.
So why deprive computer music grad students of their favorite
industries? It is probably the primitive syntaxes of csound programs
and data that make it so inviting and possible for even relatively
inexperienced programmers to generate such a startling variety of these
tools.
"Dynamic Library Linking" is another thing entirely. I think it is
very important that some interface to (and unfortunately from) the unit
generators be decided upon among those maintaining the common ports and
implemented, preferably one that allows the OENTRY structure array in
"entry.c" to propogate unmolested, because it would allow for the
common ports to provide bases for unit generator development without so
much code twiddling. Although I'm sure it is wonderful, I cringed
compiling "marimba" into the Mills port. With "DLL" we could return to
a reasonable set of "canonical" unit generators and have available to
us libraries of (and documentation for) anything anybody might dream up
(and let those anybodys be responsible for cross platform coherence of
their products). I remember Csound as music-11, and sometimes I
sometimes yearn for the days of the 40 page manual when "foscil" seemed
controversial, but that won't again be the case, I'm afraid.
It has been suggested recently in this group that this DLL issue is a
*lot* simpler than it really is from a programmer's viewpoint,
involving "two or three" (if I remember right) hooks into the current
code. The number may be right, but where, when, how, whatif, whatif,
whatif, whatif, whatif, whatif, etc., etc., etc. It also adds to the
people supporting the ports the onus of supporting a development
environment, including questions like "what if I want to do an FFT,
print a message, read a soundfile, fry an egg, blah, blah, blah" from
my unit generator. These symbols would need to be exported to the unit
generator developer from the Csound binary. Right now unit generator
libraries just call whatever willy-nilly, having all external (and in C
potentially recursively referenced -- ||: boom! :||) symbols available
at compile time. Getting MIDI, with its basically trivial and
high-level system dependencies, just from 3.46 to 3.47 recently caused
a few people a *lot* of grief. This is not trivial.
Nonetheless, the DLL (a Wintel term, BTW) issue must be addressed,
together, by the people doing the ports with input from the community,
an impossible task before 3.47 is cross port stable.
And we thank you for your support...
Dave
Dave Madole
Technical Director, Center for Contemporary Music
Listserv Administrator
Mills College
Oakland, CA 94613
510-430-2336
madole@mills.edu |