Thanks for your response. I will address your points in the order raised.

>Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?


C is still a little bit faster, and Csound is written almost entirely in C.

>
>> Plugin unit generators.
>> Plugin function tables.
>
>Flexible growth for Csound. Will direct loading of Csound Plugin UGs by
other
>frameworks be allowed ? Why not make it a universal Plugin interface for
UGs ?


Fortunately or unfortunately, Csound UGs need access to global objects in
the Csound kernel, notably various rate variables and the function table
array. They cannot really work in isolation. If the UG "type" were changed
to perform this access through an abstract interface that other applications
could implement, it would work, but then that would be an even deeper
rewrite of Csound than I am contemplating.

>I hope there will be many candidates. I doubt I'll be able to participate
in
>the coding (i wish i was government funded like you all lucky academics),
but
>as a potential user I am very interested and would love to be informed of,
and
>if I can at all contribute to, this project's developments.


I am not an academic. I have a fulltime day job as a C++ programmer.



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html

>Fortunately or unfortunately, Csound UGs need access to global objects in
>the Csound kernel, notably various rate variables and the function table
>array. They cannot really work in isolation. If the UG "type" were changed
>to perform this access through an abstract interface that other applications
>could implement, it would work, but then that would be an even deeper
>rewrite of Csound than I am contemplating.

Michael - this isn't true. There is no reason to change the UG "type"
in order to provide access to rate variables and function tables.
I know this because I've done it in Quasimodo. This is certainly true
for Unix dynamic libraries anyway, and I was under the impression that
the Windows DLL's worked similarly. Perhaps not. 

BTW, Quasimodo also changed the UG argument type to be a C++ object,
which allows much greater flexibility and also allows you to use the
compiler to take of allocation, which avoids some of the silly
problems with alignment that regular Csound has had on 64 bit machines.
However, the object looks identical from the point of view of an
opcode function.

Also, as far as C++ goes, although its true there is often a small
speed penalty even for identical code, in the places where it matters
(execution opcode functions), egcs spits out almost identical code for
C or C++ compilation. There's really nowhere else in Csound where the
difference between the two languages makes a significant difference in
terms of speed.

--p