Michael Gogins wrote:

[snip]
> 
> 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