[gmpi] Re: Topic 8: Parameters
- From: "Frederic Vanmol" <frederic@xxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Fri, 8 Aug 2003 22:34:33 +0200
You make problems where there are none (IMHO).
A plugin has one state, that of its latest version. However, since it's
interesting to be able to load settings, you can send an old chunk (I'll use
the VST term) to the plugin and it will be able to interpret it. That's my
main reason for wanting chunks. Let the plugin handle those problems, since
it knows what to do in every specific case. The host can only aspire to
provide a good-enough generic solution, and then plugins will have to use
workarounds to get more exotic results. Again, just my opinion.
Frederic
----- Original Message -----
From: "Marc Poirier" <fipnid@xxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Friday, August 08, 2003 9:53 PM
Subject: [gmpi] Re: Topic 8: Parameters
> This is a very interesting idea. It might be just the solution, but I've
> got a few qualms...
>
> One thing is that I don't like the idea of the plugin behaving as though
> it were another version, changing its parameter list to match that, etc.
> I think that the better expectation is for the plugin to, if possible,
> interpret those old or new settings as best it can and incorporate them
> into the plugins current behavior. And if that can't be done, then the
> plugin would have returned an error from SetVersionState.
>
> Another issue is that, when the host does SetVersionState, how long is
> that applicable. For the entire life of the plugin instance? That
> doesn't seem good, because there will be parameter tweaking using the
> interface of the plugin as it is now. We would not want the plugin to
> take those parameter value changes and interpret them as though they came
> from a different version of the plugin. Or does it apply until the host
> next does SetVersionState (which could be never, so I guess that's the
> same as saying that it applies indefinitely)? Maybe the protocol should
> be:
>
> nowversion = GetVersion
> if (nowversion != saveversion)
> error = SetVersionState(saveversion)
> if (error)
> fail
> while (iterating through every parameter)
> setparameter(ID, savedata[ID])
> if (nowversion != saveversion)
> error = SetVersionState(nowversion)
>
> So in the end, you cap off your settings restoring with another call to
> SetVersionState to say, "okay, now you can be yourself again."
>
> Anyway, just my thoughts, this seems like in general it could be a good
> solution, in my opinion...
>
> Marc
>
>
>
> --- Mike Berry wrote:
> > I think we can make a simpler system than this. Imagine this API:
> >
> > GMPIError GetVersion(int* outVersion);
> > GMPIError SetVersionState(int inVersion);
> >
> > All plugins must support GetVersion. It is the host's responsibility to
> > store the plugin version number when it saves a project containing the
> > plugin. Upon opening that project, the host calls GetVersion on the
> > plugin that it loads from disk. If GetVersion does not equal the saved
> > version, then the host calls SetVersionState on the plugin. The plugin
> > has two choices:
> >
> > 1.) Support the requested version. This means that it adapts its
> > parameter list and behavior to match the request version, but only for
> > the specific instance of the plugin that SetVersionState is called on.
> >
> > 2.) Return an error. This means that the plugin is incompatible with the
> > requested version, and the host cannot restore the state including this
> > old, out-of-date plugin data.
> >
> > This is not complicated for the host, and is not complicated for plugins
> > whose version change but which remain completely compatible across the
> > versioning. It only impacts plugins which do change enough to require
> > interpretation, and the interpretation is left up to the plugin, which
> > can always refuse. The host then knows that the plugin bahvior for a
> > saved project will always be either the same on reload, or completely
> > unavailable, either one of which is much easier than having to have the
> > host do reinterpretation.
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ----------------------------------------------------------------------
> 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
>
----------------------------------------------------------------------
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:
