>Mmm, one begins to see the potential power of such a system, given such a
list
>of interfaces!
>
>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.


Yes.

>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.


I thought I had made that clear. An ActiveMovie plugin is ALSO a COM server,
another kind of COM server - any library or application with a COM interface
is a COM server.

My original idea was for something to fit together with my WCSound front
end, and in the back of my mind I was thinking of ActiveMovie plugins and
other plugin formats (like VST), but your posts caused me to bring this
topic to the foreground, and helped greatly to clarify the issues.

Obviously the real power of a general-purpose software synthesizer is to be
able to plug into the most flexible, most widely used plugin
architectecture, which appears to be ActiveMovie (AKA DirectShow).



>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.