Apropos the following, let me emphatically agree that re-entrancy should be
the first goal. Basically, I would like to have a C++ class that is Csound
and has a re-entrant Play() function. If I had that, I would go ahead and do
the COM stuff myself in a trice.

Shortly, I will propose such a class for Csound. I will attempt to put in
hooks for the DirectShow stuff that we have been talking about - places
where all of the significant inputs and outputs of the program, whether file
or real-time, can be accessed, hopefully in a synchronized way. I think this
is a minimal foundation for what we have been talking about. I'll solicit
feedback on the design of this class. All work that I do in public like this
will fall under the terms of the GNU Public Library License.

Once this class has been defined, perhaps we can go ahead and actually
install Csound in it and try to make it really re-entrant.

In all work of this sort, it's most extremely advisable to keep things as
simple as possible.

Does anyone reading this list have experience with SAOLC? How capable is it
compared with Csound? I'm not as interested in how easy it is to do
something as I am in whether it is possible at all.

>Richard Dobson wrote:
>> Well, making Csound re-entrant will benefit all platforms. COM is indeed
a
>> Microsoft invention (though they do have a version for the Mac, and are
trying
>> to extend it to unix through DCOM - Idon't know how realistic this is, or
how
>> much take-up there is), so the particular ideas Michael Gogins and I have
been
>> exploring are indeed specific to that platform. I do think that once the
>> re-entrancy has been achieved, developers on all platforms will jump at
the
>> opportunity to create all manner of powerful facilities.
>
>I think re-entrancy should be the first goal.  One this is achieved, all
>sorts of server functionality can be achieved on many if not all of
>Csound's platforms.  Focusing on COM or on any other specific API at this
>point will fragment the efforts of Csound developers...
>
>Looking at the code for Csound, I'm struck by its two-pass nature: a parser
>builds instrument files into complicated data structures representing the
>instruments, while another parser turns score files into a chain of data
>structures representing "notes."  The result of these two parsings is then
>fed to a "virtual machine" that does the actual calls, via function
pointers,
>to the various units, based on the chain of note events (and optionally,
>additional events generated via MIDI or other real-time sources).