[gmpi] Re: Topic 8: Parameters

  • From: Marc Poirier <fipnid@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 8 Aug 2003 11:17:11 -0700 (PDT)

--- Tim Hockin wrote:
> > Ahhhh, okay, I get your concerns now.  You're totally right, simply
> > running running through every parameter and saving its data /
> > restoring its data is not sufficient to save and restore state when 
> > your dealing
> Baloney!
> :)
> /* on save */
> add_to_patch(patch, "version", plug->version);
> for each parameter p in plug
>       add_to_patch(patch, plug->param_path(p), plug->get_param(p));
> save_patch_to_disk(patch);
> /* on restore */
> if (plug->version == get_from_patch(patch, "version"))
>       for each parameter p in plug
>               plug->set_param(p, get_from_patch(patch, plug->param_path(p));
> else
>       error("can't load this patch - versions don't match!\n");
> Version information is definitely stored with any clump of state, that
> is a non-issue.

No no no no no no no, the *plugin* needs to know what the version is when
restoring the state.  The host can't make those kinds of decisions, that's
crazy!  If you can't load settings from one version of a GMPI plugin to
another, believe me, NO ONE is going to go for GMPI!  Sometimes, sure, it
will not be possible for a plugin to use an older or newer version's
settings, but in many (most?) cases, those settings are completely
compatible, or if not, the plugin can still interpret them.

> The REAL issue is whether people prefer this method, or whether people
> prefer the plug->get_state(), plug->set_state() pair, where the entire
> state of a plugin is opaque.  Either one can work.  One is not 
> inherently better than the other.  There are reasons for both.

While I don't agree that that's the "REAL issue" (see above), it is
another issue.  And my opinion is that I like the all-parameter-data
approach better than the one-big-blob approach.


Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

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: