[gmpi] Re: Topic 8: Parameters
- From: Marc Poirier <fipnid@xxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 8 Aug 2003 19:56:12 -0700 (PDT)
--- Frederic Vanmol wrote:
> 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.
Mine too, so I'm not sure I understand what you're disagreeing with. The
only difference between what you've said and what I've said is that you
want everything in one blob and I (and some other folks) would prefer
parameters to be sufficient.
But I think that what us param-advocates have failed to do is to
articulate why we don't want the single blob for state. I for one can say
that, for the sake of programming sanity and data longevity, I prefer to
avoid opaque data blobs as much as possible. If you look at what those
data blobs hold in VST, for example, a lot of it is universal to every
plugin. You know that they all hold the values for every parameter and
the plugin's version, at the very least. Then there's other stuff in
addition (otherwise the plugin would not have bothered to go with blob
state description). If you want to create more usable, readable, and
longer living data, you are better off standardizing the universal data.
Take the Destroy FX plugins that I have co-created. For VST, we have used
"chunks" for state data. The reason is because we want to save the MIDI
CC -> parameter assignments (our plugins allow for "MIDI learn"). So we
made a data format for that, and it stores version, every parameter value,
and every parameter CC assignment. We also tried to build in a bit of
better version control in there, too. At a certain point, we realized
that we hadn't done such a great job with it, and in order to fix it up,
we made changes that made it too difficult to try to keep backwards
compatibility with the old format. So now then you couldn't load any old
settings anymore. Big bummer. Now we are about to do that again, because
of some other major internal changes. So that's twice that we completely
killed settings backwards compatibility, simply because of settings data
format issues, because a changes in blob format can be too much of a
nuisance to deal with.
This really sucks, and basically it comes down to single blob settings
data thingies being an unecessarily unweildly thing. The reason why I say
"unnecessarily" is because you could just universalize the saving and
restoring of the universal stuff (parameters and version) and then only
chunkify the extra stuff. I think that doing it that way is better for
everyone.
So for me personally, I see the two best options as:
1) Everything is a parameter, including opaque data, and restoring state
is no different than setting parameters, but somehow the host needs to
clue the plugin in to version mismatches (possibly inelegant).
2) Restoring data involves restoring all parameter values and optional
data blob(s).
Regarding 1, Tim Hockin, who has said that he likes the
everything-is-a-parameter approach, did also say that my idea for version
control with restoring state for that approach was "even less pretty than
a single state blob." I think I agree, but maybe someone else can come up
with a better idea...
Regarding 2, that's basically how AU does it. State settings are stored
as XML with several standard keys and values: version, plugin identifiers
[type, subtype, and manufacturer IDs], the name of the state settings, the
version of the settings format [i.e. the version of that standardized AU
settings format, not a plugin-specific version], and then an array of all
of the parameter IDs and values for each scope (which are all float values
in AU). Then the plugin can store additional data in its own custom keys.
Since it's XML, that data can be numbers, opaque data blobs, strings,
etc. But doing it this way, at least all of the universal data is
transparent and "protected" by a standardized format.
Since idea #1 has some ugliness, maybe #2 is the best. Having worked with
the AU format, I do like it. But in my opinion, the
everything-as-one-blob idea is not at all attractive.
Marc
__________________________________
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:
