Mmm, one begins to see the potential power of such a system, given such a list
of interfaces!   

Prompted by all this, I have done some more browsing through the DirectShow v5
docs, and gleaned the following:

There is a special mechanism for registering ActiveMovie filters (using the
IFilterMapper2 interface), which places a filter in one or more of the defined
filter categories - it IS possible to register as both a source and a transform
filter. It is even possible to create  a new category - there is a method on
that interface to do just that; I need to find more information. 

The Filter Graph Builder interface IGraphBuilder is NOT implemented as a dual
interface (though most other DirectShow interfaces are), so one cannot
manipulate it directly using automation. I presume this means you would need to
implement your own proxy interfaces (perhaps by setting up Csound as a PlugIn
Distributor?) if you need that facility.

While you are looking at Csound primarily as a COM server, accessed through
automation, I am especially interested in the possibilities of it as a
main-category ActiveMovie plugin, which means that it must be registered as
such, so that applications such as Sound Forge can find it, without needing to
know about Csound. So, just as CsoundX can implement and/or use DirectShow
interfaces, the obverse may also need to be true, one way or another.

One technical issue I think needs looking at: ActiveMovie expects more
flexibility regarding sample rate than Csound currently offers. In Extended
Csound, they get round this problem by resampling audio data on the host to the
orchestra srate (which is currently 32KHz 'for historical reasons'). It is done
very well, but it is a pity it has to be done at all. Ideally, when Csound is
acting as a transform filter, it should accept and use the srate of the input
stream, and preferably, deal with different channel-counts in a tolerant way as
well. This will become a more pressing issue as multi-channel formats become
more commonplace.

I am very intrigued by your suggestion of Csound as a factory for plugins. Could
you elaborate?

And, realistically, there is still a way to go to get Csound
re-entrant...faster...


Richard Dobson

Michael Gogins wrote:
[snip]
> 
> 
> What is needed is for Csound to either implement, or better contain and
> expose, several different interfaces. It would provide something like:
> 
> Csound.WaveInput
> Csound.WaveOutput
> Csound.WaveTransform
> 
> Csound.MidiInput
> Csound.MidiOutput
> Csound.MidiTransform
> 
> Just off the top of my head (C++ style, all returning HRESULT):
> 
> Csound.Opcode(long index, VARIANT *pOpcode)
> Csound.FunctionTable(long index, VARIANT *pWavetable)
> Csound.SetFlag(BSTR Flag, BSTR Value)
> Csound.GetFlag(BSTR Flag, BSTR *pValue)
> Csound.GetSamplingRateHz(long *pValue)
> Csound.SetSamplingRateHz(long Value)
> Csound.GetKontrolRatio(long *pValue)
> Csound.SetKontrolRatio(long Value)
> Csound.GetChannelCount(long *pValue)
> Csound.SetChannelCount(long Value)
> // As an alternative to the above suggestion....
> // Some sort of access to get and set filters... Obviously this is wrong,
> but you get the idea.
> Csound.EnumerateFilters(long Index, VARIANT *pFilter)
> Csound.Play()
> Csound.Stop()
> Csound.Pause()
> Csound.Rewind()
> Csound.SetCue(double Time)
> Csound.GetCue(double *pTime)
> Csound.GetFilterGraphManager(VARIANT *manager)
> // Some utility functions for encapsulating setup of filters for writing
> soundfiles, reading soundfiles, etc. by name)
> 
> Opcode.Initialize(ICsound *csound, VARIANT *pfields)
> Opcode.OnAudioSample()
> Opcode.OnKontrolSample()
> Opcode.Finalize()
> 
> FunctionTable.Initialize(BSTR fStatement)
> FunctionTable.GetTable(double **data)
> 
> CsoundX an ActiveX GUI that knows how to make and control a Csound object.