I would like to do things the right way and not circumvent the spec, but...
it will only take one non-compliant but popular host app to topple things;
all the plug developers will be scrambling to find workarounds. One way to
combat this would be to have the reference code include both a prototype
host and prototype plugs that exercise as much of the interface as possible
so that both host and plug developers can demonstrate compatibility. I know
we're already planning this to some extent - it's very important.
So, yeah, I'm on board with doing things the right way, with the
understanding that the only way to really mandate design practice is to
have a thorough reference and enforce compliance. In the case of GUI to DSP
communication, it may not be that easy to design the reference to catch
implementations that bypass the host, unless of course the GUI and DSP are
allowed to be in separate processes, in which case the reference host
deliberately puts them in separate processes to see if they communicate
correctly. In the case of DSP threading, the reference plug could set up
some test to verify that the host only calls one DSP method at a time.
Bill
At 02:21 PM 4/15/03 -0400, you wrote:
Marc, I agree 100%.
======================================================= Angus F. Hewlett, Technical Director FXpansion Audio UK Ltd - http://www.fxpansion.com =======================================================
On Tue, 15 Apr 2003, Marc Poirier wrote:
> > We'll have to decide if the spec mandates that the GUI and DSP communicate
> > through the host. I agree it is potentially the cleanest implementation,
> > however, it is also quite likely that such mandates will be circumvented by
> > developers. After all, it will be easy enough to communicate a pointer via
> > the interface and then use it directly, being careful to handle thread
> > synchronization. I sheepishly admit doing this in DirectX . The proper way
> > to do it is using COM interfaces and data marshalling, in case the GUI and
> > DSP are in separate processes. My point is that the spec can mandate one
> > design, but the actual specification is the legacy left behind once
> > developers implement a lot of plugs. If everyone takes the same shortcuts,
> > it tends to alter the specification in practice. My guess is most existing
> > Dx plugs will not work if the GUI and DSP are in separate processes even
> > though in theory they should.
>
> Ummm... existing DX plugins aren't going to work as GMPI plugins anyway.
> They will need to be updated according to the GMPI API. This concern is
> irrelavent, isn't it? Or am I missing something here?
>
> > My vote would be to assume all components of a plug (including GUI and DSP)
> > are in the same process, provide a nice host messaging interface, the use
> > of which means that thread synchronization does not have to be handled by
> > the plug, and don't mandate that all communication must pass through the
> > host, but make it so attractive and easy to use that everyone does it this way.
>
> I disagree. You're point is that even though you like this cleaner
> design, developers have circumvented it in the past so we should forget
> about it, because that cheating software won't work if it becomes
> impossible to get away with the circumvention. Well, I think that
> developers will stop circumventing it if they can't get away with that
> anymore. Let's not give up before we even started and pander to
> developers' laziness. Let's do things right from the beginning and let
> the developers start doing things right before they accumulate a
> collection of legacy code that fails to meet our needs and expectations in
> the near future.
>
> Marc
>
>
> ----------------------------------------------------------------------
> Generalized Music Plugin Interface (GMPI) public discussion list
> Participation in this list is contingent upon your abiding by the
> following rules: Please stay on topic. You are responsible for your own
> words. Please respect your fellow subscribers. Please do not
> redistribute anyone else's words without their permission.
>
> Archive: //www.freelists.org/archives/gmpi
> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
>
>
---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
---------------------- Bill Gardner Wave Arts, Inc. 99 Mass. Ave., Arlington, MA 02474 Tel: 781-646-3794 Fax: 781-646-7190 billg@xxxxxxxxxxxx
---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
