[gmpi] Re: Topic 5: Threading
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 15 Apr 2003 14:21:34 -0400 (EDT)
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
Other related posts:
