To address the points below:

I didn't know about the init functions compilable #ifdef RESET.  Thanks for
the news, sounds great, and I'll try it right away.

As for the current Windows GUI, I would prefer to go ahead and create a
Csound COM object with property pages for a user interface, and a shell EXE
to run that as a standalone application. I have done work similar to this,
and could produce this quite quickly.

Finally, as for assembler for casting float to int, I'm actually not that
interested in doing that myself, because I plan to work exclusively in
floating point using soundfile editors and players that handle that, such as
Cool Edit Pro. But if someone else wants to do this, or can provide
foolproof instructions for doing it, I'd be glad to incorporate it. I do
appreciate the value of being able to have things happen in real time.

>> I want to avoid unnecessary work, and I have no intention of doing
anything
>> more than the bare minimum required to get Csound re-entrant in the first
>> phase, and working as a transform filter in the second phase.
>
>This was more-or-less the situation I reached last year. I simply created
an
>'init' function for each module, which was called in main(). I was able to
run
>several orchestras over and over, without errors or memory leaks. That was
using
>Csound V.3.45. John Fitch has preserved these init functions in the current
>sources, under #ifdef RESET. So we should be able to leverage that stuff
and get
>something going farirly quickly.
>
>Perhaps we need to fix on a particular working version, say 3.478, or
whichever,
>and settle on some core test orchetstras which we all use to validate the
>re-entrancy code. With care, the Winsound GUI front end can work adequately
to
>drive everything; though at some point a more Windows-friendly (and
simpler...)
>version might haver to be created just for this task.
>
>Re plugins: although they are not ~required~ to run in real time, most
users
>will want to wherever possible. There may therefore be a case for some
strategic
>optimisations in assembler, given that plugins are utterly
platform-specific. I
>am thinking, for example, of the places where blocks of data are converted
from
>floats or doubles to shorts. This is actually quite a slow operation, as
the
>cast (under VC++) involves a function call to reconfigure the fpu to
truncate,
>instead of round). By writing an assembler routine to do this block
casting,
>significant speedups can be made (factor of three, from my recent
experiments).
>There is some interesting information about this on Intel's web site (in
>relation to their own C++ compiler - plugs into Developer Studio - which I
am
>tempted to try, but its another 100MBytes to put somewhere...)
>
>Richard Dobson