[gmpi] Re: 3.14 UIs
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sat, 29 May 2004 14:55:00 +1200
> On the other hand, are we sure param get/set a rich enough model for
> communication between the custom GUI code and the DSP code? I'm
> thinking about some of the great intricate signal displays we're
> seeing these days, seems like they could, perhaps, be needlessly
> cumbersome to express in those terms.
Hi Chris,
In anticipation of GMPI, I'm currently converting my code to use this model.
It does require a shift in thinking. To display say, a Spectrum Analysis on
the GUI, the data is passed from DSP to GUI via the host as a 'parameter',
( a binary-object parameter ).
What i'm finding, is that by using parameters for all communication between
DSP and GUI, both DSP and GUI code become very straight-forward.
My plugin dosn't need locking code, or shared memory, It dosn't worry
about threading issues. ( The burden of inter-thread communication is
centralised in the host* ).
It's a very 'clean' design, I've been able to delete a lot of code from my
plugins.
*In my case I'm still producing VST plugins, even so, it's been a big
advantage to rip out all the inter-thread communication and put it in one
place, a GMPI emulation layer that sits between the VST host and my plugin.
When real GMPI is available, I'll just remove the emulation layer.
It means I'll be able to support both GMPI and VST from the same code
base.
Best Regards,
Jeff
----------------------------------------------------------------------
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:
