| I think this is a most important post - definitely more than two cents!
:-)))
The more I have thought about it, I feel that the focus of any language
enhancement should take the form of an orc preprocessor or compiler. The
orc syntax and opcode structure is similar enough to that of a machine's
instruction set (albeit CISC, not RISC!), and has all the essential branch
instructions; the code generation stage of this compiler would create an
entirely standard orc file. The compiler (which might, of course, be a
graphic tool such as PatchWork) would not need to know how the orc file is
parsed or used - it could be in optimized assembler for all it cared. One
special aspect of the compiler, however, could be the ability to define
opcodes either explicitly (clever but difficult!) or by importation; all
(?) that would be required of Csound is a formal mechanism for interfacing
to the opcode module.
And, as you point out, there is still plenty of work to be done
strengthening CSound itself in the light of new requirements!
Richadr Dobson
David Madole wrote:
> 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
|