generic dsp plugin format

[Michael Gogins]

The message below requires clarification. My original post proposed COM as
language and platform independent ONLY as an interface specification - which
it is. In this regard, it does not require any runtime libraries at all. As
I said before, used in this way, the audio plugin objects would have to
provide their own, non-COM implementations of their object factories, so
that it would not be necessary to call CoCreateInstance to get an interface
to an object.

If, on the other hand, one desires operating system support for COM, which
one must if one uses predefined interfaces in any depth, then what Chris
says is quite correct - cross-platform COM support is new and not widely
tested.

-----Original Message-----
From: Chris De Chiara <cd at xnet.COM>
To: Multiple recipients of list <music-dsp at shoko.calarts.edu>
Date: Wednesday, November 18, 1998 12:08 AM
Subject: RE: generic dsp plugin format


>
>I've been reading this thread, although not very carefully, and I hope you
>won't misunderstand my comments. As I do not want to start a holy war. But
>COM has some very serious drawbacks. It really is a Windows only design
>specification. It depends entirely on a runtime library, dcom.dll and I
>have tried ports to Solaris with two well known commercial products,
>without any success. It is however the best way to go if Windows is your
>only concern.
>The idea of COM being language independent and platform independent is
>extremely misleading, as languages are independent only if you remain in
>Windows. Microsoft has wrapped a lot of misleading information around DCOM
>and COM+, as my company is currently finding out. (A multimillion dollar
>project we built around COM is facing very serious problems and may never
>make it to market) Forget about COM behaving with CORBA, having accurate
>message passing between platforms or protocols, or languages, especially
>JAVA - even with the MS JVM ,or even by itself, in many cases.
>
>Again, if your goal is Windows, COM is a great choice, in fact Microsoft
>has assured that it is really your only viable choice. If you want portable
>code, ATL, MFC, or COM/DCOM is not the way to go.
>
>An upcoming issue of Distributed Computing will feature an interesting
>article on choosing COM or CORBA.
>
>Chris
>
>At 01:27 PM 11/17/98 -0800, you wrote:
>>> -----Original Message-----
>>> From: music-dsp at shoko.calarts.edu [mailto:music-dsp at shoko.calarts.edu]On
>>> Behalf Of Ross Bencina
>>> Sent: Monday, November 16, 1998 10:18 PM
>>> To: Multiple recipients of list
>>> Subject: Re: generic dsp plugin format
>>>
>>>
>>> [regarding COM and C++ interfaces]
>>>
>>> Richard Dobson:
>>> >>Almost all the DirectShow interfaces are implemented as 'dual'
>>> >>interfaces, which means that applications such as VB (or even the VB
>>> >>scripting used in Excel, etc) can control a filter graph, load
filters,
>>> >>manipulate pins, and so on. I have done no more that read about any of
>>> >>this, but I get the clear impression that it is possible in principle
to
>>> >>run DirectShow from VB, instantiating a filter graph and loading
>>> >>filters, effectively making VB a scripting language for plugins.
>>>
>>> Yes this is what I have read also... I have looked a bit futher and it
>>> appears that although you can connect filters together with VB (which in
>>> itself is pretty cool)... the only way you can manipulate the
>>> parameters of
>>> a plug is through the (manufacturer provided) visual control panel -
there
>>> is no (standard) way to grab synthesis parameters (filter cutoff for
>>> example) and tweak them from VB code - and even if there was I'm
>>> not sure I
>>> would be wanting to use IDispatch for high speed krate type control.
>>> _please_ someone correct me if I am wrong.
>>
>>OK. The way that a property page object manipulates a filter is through
>>a specialized custom interface for that filter. If the creator of the
>>plugin supplies you with the details of that interface, you can do the
>>same sort of manipulations. Most filter interfaces are not dual, the
>>IDispatch interfaces are provided for manipulating the graph as a whole
>>from VB or scripts.
>>
>>> There are advantages to using COM... and I don't think we really
>>> need to go
>>> into them here (although I would like to hear an opinion of COM function
>>> call overhead)... one disadvantage of COM is that there is a
>>> steep learning
>>> curve...
>>
>>COM function call overhead is identical to calling a virtual function
>>in C++ (when the object is running in-process). The learning curve is
>>pretty steep, but the knowledge is useful for virtually all aspects of
>>Windows programming these days. I know that ports of COM to various
>>platforms are a hot topic, but I have not personally tried any of them.
>>
>>> I think the plug interface would be C not C++ - there won't be that many
>>> exported functions that C++ would make a difference anyway.
>>
>>The nice thing about COM is that the interface is not C or C++ (or
>>Java, or VB, or...). Language independence is a pretty cool thing.
>>
>>Tony Hefner
>>Senior Engineer - Sparta, Inc.
>>arh at mclean.sparta.com
>>
>>
>>
>____________________________________________________________________
>Chris De Chiara
>cd at xnet.com