[gmpi] Re: 3.11 topic: Dynamic plugin structure
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Mon, 26 Apr 2004 13:15:41 +1200
> What I like about the modules approach I described before is that it is
> largely host-based (It might come from a custom GUI, but the host does
> it). The host sees the list of modules available on a plugin. The host
> is responsible for telling the plugin when to change it's modular config.
> The host is responsible for storing/loading modular state.
>
> Here's a flipped model. Make the plugin do everything. When the config
> wants to change, the plugin issues a 'gestalt' request (or something).
> Gestalt means that the host must re-query the plugin. Anything might have
> changed - parameter list, parameter meta-data, IO configs, etc. The
> module state must be some extra piece of state information that is
> saved/loaded with the parameter state.
Hi Tim,
Both options support a modular approach. I quite like the 2nd option.
"The module state must be some extra piece of state information"
AU does it in a very generic way, the plugin has "Properties", unlike
parameters, properties are not automatable. They're stuff that dosn't
change much (plugin name, parameter list etc).
e.g. your mixer might have a custom property "number of mixer strips", when
the user changes that property, the plugin does the "Gestalt" thing( host
re-queries the parameter-list, and IO info). The host then discovers some
new parameters ( Vol, EQ etc for the new strip)
The host dosn't 'see' modules as such, just simple properties. This gives
the plugin freedom to use a modular approach internally, or not.
>Ron says...
"I personally don't like the approach that says new parameters need to be
exposed via new modules. It puts an unecessary burden on a plugin that
wants dynamic parameters (or pins), but isn't necessary modular."
So, I think we can please everyone.
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:
