[gmpi] Re: Topic 8: Parameters
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 8 Aug 2003 11:01:28 -0700 (PDT)
> So what if you (the plugin) want to save stuff that you don't want to publish
> as a parameter? A version number comes to mind.
I see data as one of:
* static data (e.g. plugin version) - this never changes during the
lifetime of a plugin instance
* state-effecting controls (e.g. filter cutoff, etc) - these can be changed
dynamically and the state of the plugin is captured by these
* non-state controls (e.g. tempo control) - these are connections to other
things in the system, but don't make sense to save in a preset
Maybe it is easier to define an intermediary.
1) everything (except static data) is a control
2) when saving/restoring plugin state, you must iterate over the plugin's
'stata' (sing. 'statum')
3) each 'statum' is associated with a control*
* separate idea, somewhere in between: each statum has a type and a
statum->get_val() method which spits out value. Typically each statum will
be associated with one control. In the case of controls which are
order-sensitive or really need to be saved/restored as a group, a statum
can return raw_data type, and internally encapsulate multiple primitive
controls.
----------------------------------------------------------------------
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:
