[gmpi] Re: Topic 8: Parameters
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 9 Aug 2003 10:42:24 -0700 (PDT)
> > How about this:
> >
> > Version doesn't matter. Every parameter/control has a 'name' (path, ID,
> > whatever). State is stored keyed on that 'name'. If a control with
> > that 'name' exists in the plugin, that's where the data goes. If you
> > want to stay compatible, keep the 'name'. If you want to break compat,
> > change it. If you want to evolve, but retain compat, make a hidden
> > control with the old 'name' which does the right thing when you set it's
>
> > value from state. The hidden control does not get manipulated from any
> > UI.
> >
> > This way, saved and restored state _REALLY_IS_ just the set of all a
> > plugin's parameters**. Compatibility is free if you are really
> > compatible, costs minimally if you need to do some hackery, and can be
> > abandoned altogether if you don't care.
>
> While I appreciate your boundless desire to make things as simple as
> possible :), I think that this is again getting too simple. It's simply
And I appreciate your desire to be compatible, but it's getting *hairy*. :)
I haven't seen in your paragraph below any reason why my idea wouldn't
work. Read on.
> not sufficient. It's often more complicated than just "we added a new
> parameter" or "we eliminated a parameter". Sometimes you might change the
> value range of a parameter in one version, so you may need to map that
> value. Sometimes what was once a single parameter is now composed of two
> parameters (like if you decided to make it into a parameter defined by a
> minimum and maximum, which can then be randomized within that range).
> Then you would want to interpret the old single value by setting both
1) range change
- make a new control** with the new range and a new name
- mark the old control as hidden (or deprecated, or for-compat)
- when a host writes to the old control name, convert it and write to the
new control internally
2) single param gets split up
- make the new controls** with new names
- mark the old control as hidden (or deprecated, or for-compat)
- when the host writes to the old control name, set the new params based
on the old value
> parameters to that value. And so on, basically I'm just saying that you
> can't come up with some solution that will just work for any plugins;
> you've got to allow them the flexibility to look at all of their state
> data and decide what to do with it. Anything less, while possibly
> enticing in its simplicity, is insufficient.
This allows for EXACTLY as much compatibility as a plugin cares to retain.
It makes it very obvious that retaining compatibility (or rather, making
changes that require explicit compat) costs code-space. There is nothing
you can't do here that your enumerated version idea can't do, is there?
** s/control/stata/
Tim
----------------------------------------------------------------------
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:
