[gmpi] Re: Summary 8.2: Parameters and saving/restoring state
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 9 Sep 2003 09:41:06 -0700
On Tue, Sep 09, 2003 at 09:58:27AM -0400, Paul Davis wrote:
> >well, i guess you means STATA = Static Data , where the size cannot be
> >changed during the life of the effect hinstance...
>
> no, i think that "stata" and "statum" are invented lexical terms
> derived from "state" not "static". i have to say that i don't like the
> use of these terms, even though the concept they are labelling seems
> fine. computer science must have generated some existing terms for
> this, surely?
Correct - state+data = stata. If you know a better name, I'm game to use
it. Atom?
> as for their size varying, i think they would work in a similar way to
> VST's getChunk, as far as i can tell from the discussion to date. a
> plugin would get N bytes of a "stata" when its state is set, but could
> return N+M bytes when its state is queried later (e.g. post version
> change, or when its state has been altered so that more information is
> required to represent it).
I wanted to write it such that stata may or may not actually be separate
from parameters. The most normalized form I can envision being useful is
one where stata have the same types as parameters (int, float, string,
chunk, whatever) but are seperate entities. Most often there is a 1-to-1
mapping of statum->parameter, but there need not be, for developers who
prefer to have a single state chunk for the whole plugin, or just an extra
state chunk that isn't a parameter, or for the oddball case where a couple
parameters get chunked together for state.
It seems a useful seperation. I'm all for changing the name, if it bothers
people.
--
Notice that as computers are becoming easier and easier to use,
suddenly there's a big market for "Dummies" books. Cause and effect,
or merely an ironic juxtaposition of unrelated facts?
----------------------------------------------------------------------
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:
