[gmpi] Re: Topic 5: Threading
- From: Marc Poirier <marc@xxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 15 Apr 2003 20:02:09 +0200 (CEST)
> 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
Other related posts:
