[gmpi] Re: Topic 8: Parameters

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

I don't like the idea that a plugin is expected to emulate older versions
of itself.  I think that that's an unreasonable burden for plugin
developers.  Maybe I'm just old fashioned, but in my opinion, that's what
hanging on to old versions of plugins is for.  If you want your plugin to
behave exactly like v0.3.9a for a particular session, then swap out your
current version and throw in 0.3.9a for the moment.  I was going to
mention the major problem that this could cause for custom GUIs, too, but
you already realize that.  :)

I'm with Frederic Vanmol on this one:  plugins should be expected to
interpret old semi-compatible settings if possible, but not expected to
emulate various revisions of itself; that's a really big development
burden and code bloater.

Marc



--- Mike Berry wrote:
>       Well, here are the goals that I as a host writer want to achieve 
> with this:
> 
> 1.) I want to be able to open an old project and render it so that it 
> sounds the same as it did when I made it, even though I updated my 
> plugins in between.
> 
> 2.) I want a plugin which was loaded in a previous version to have 
> exactly the same parameter structure now as it did before. That way I 
> do not have to rearrange all of the controls and possibly add or 
> remove controls.
> 
> 
>       I agree that this brings up an interesting question relating to  
> custom UI that the plugin might provide. One solution is for the plugin 
> to tell me if the custom UI is still available while it is running as 
> an old version. This could be part of the return value from 
> SetVersionState. If not, then I can disable the ability to access the 
> custom UI, but the plugin can still be used to render like it used to.
>       I think that once an instance of a plugin was set to a particular 
> version state, it would not be reset. This could even be passed as part 
> of the plugin creation method, so that the order would be:
> 
> 1.) Query the plugin object for its version.
> 2.) Create a plugin passing the version state that you wish. This cannot
> be changed later for this instance.
> 
> The create method would then fail if the older version was not supported
> 
> anymore. Or the plugin would be created but say that it does not have 
> custom UI, because that is not supported. Or it would return fully 
> successful, and operate just as if it were the old version. For some UI,
> 
> this might simply mean disabling controls that had been added.

__________________________________
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

Other related posts: