[gmpi] Re: Requirements
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 17 Nov 2003 09:43:10 -0500
>Here's the platform independent version <g>:
>
>struct WindowState
>{
> size_t cb;
> char pData[1];
>}
>
>Or you could just pass a void* for a Window handle (or whatever Mac O/S
>needs).
>
>We *need* to do something like this in GMPI, to maintain feature parity with
>exisitng plugin APIs.
i happen to know that for reasons associated with looking into the
future and seeing FX "render farms" (amongst other things), there are
at least a couple of significant plugin manufacturers who are moving
toward a much more decoupled architecture for their plugins+pluginGUIs.
the reason for the tight coupling between the DSP and GUI side of
things is, lets be honest, that it was easy and perhaps in part
because windows doesn't really allow for any other way. TDM doesn't
work this way, and people deal with it because (i'm guessing here) the
SDK makes it pretty painless. programs like jMax have demonstrated for
many years that you do not *need* this kind of tight inprocess
coupling for responsiveness.
we can't necessarily force people towards decoupling just by making
GMPI do this, but i don't think we should design GMPI with our heads
collectively stuck in an accident/mistake/side-effect from the past.
>IMO we don't need something like VSTGUI.
do you see any merit in the goals (ignore the implementation) of
VSTGUI?
----------------------------------------------------------------------
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:
