>This sounds like very much like a full-blown ActiveX control. It should
>certainly be reasonable  to add supoport for DirectShow interfaces (like
any COM
>interfaces). How would it be registered?

The usual way - drop it on RegSrv32.exe. It would come with a standalone
"shell" that would register the COM library, also.

>As well as being an ActiveX control, in
>DirectShow it could qualify as both a transform filter, and as a source
filter.

That is exactly the idea.

>
>Re a GUI: I think it would need to support a property page - or several.


It might need a property page for controlling how it would appear in the
context of a containing window, like a Visual Basic form,
but really it mainly needs an embedded window for the actual user interface.
I have done these several times. Or maybe just a popup window.

Bear in mind, creating a full-blown ActiveX control is not necessary to make
Csound competitive with other software synthesizers and effects plugins. But
even if it were necessary, it is much eaiser with the ActiveX and Active
Template Library wizards.

Again, the main problem is not ActiveX, but the Csound process itself.


>Michael Gogins wrote:
>>
>> Here are some features I'd like to see in a COM server version of Csound:
>>
>> It would be an in-process, apartment-threaded COM server with a dual
>> interface. This would make it easy to use both from C++ and from Visual
>> Basic and it could also be used with Microsoft's J++ version of Java,
which
>> can automatically generate a Java proxy for most COM objects.
>>
>> It would have no self-contained GUI.
>>
>> It would have plugin opcodes and plugin function tables. These would use
>> their own COM interfaces. This would allow Csound to be extended without
>> having to relink it.
>>
>> Csound would work with standard COM interfaces to MIDI and audio drivers,
>> i.e. DirectSound or ActiveMovie (I need to do some research about what is
>> possible).
>>
>>