[gmpi] Re: Decision time: 8.1

So I've been thinking about the parameters issue.  I like some of the
proposed language.  Before fully agreeing though, I want to think out loud.
Coming back to the top of this email, it got longer and more complete than I
expected.  How does this sound, not necessarily as spec language, but as a
hashing of ideas; a data model.

First, the requirements I think I gathered from discussion.

Parameters:
a) are manipulated by user interfaces (GUI)
b) are manipulated by controllers (other plugins, MIDI controllers)
c) can be automated
d) can output values for other parameters
e) are observed (GUI, motorized MIDI controllers)
f) can be hidden or visible
g) are the source of data for state save/restore (presets, projects)

So a general statement could be:

   "A Parameter is anything that is changeable in real-time."

Parameters have all sorts of meta-data, such as datatype, range, etc.  This
alone is not sufficient, however.  Parameters need to be able to receive
changes from a number of sources.  Similar to Parameters, and usually
related are Control-Inputs.

   "A Control-Input receives events.  Each Parameter has a Control-Input."

Every Parameter has a Control-Input, which is how Parameters get changed.
Because we want to be able to connect plugins together, there must also
exist Control-Outputs.

   "A Control-Output generates events."

It seems reasonable that we might want to generate very specific data (e.g.
a tempo controller) or very generic data (e.g. a generic sine controller
which can be connected to any Parameter).  Therefore, it seems not
unreasonable to have the Control-Outputs identify themselves as outputting
normalized or natural data.  Perhaps Control-Inputs can flag themselves as
such, too.

Because of the simple Control-Input model, any number of sources can
manipulate Parameters.  This includes automation playback, which is really
just another event source.

   "All Parameters can be automated."

Because there are likely to be more than a single interface for a Parameter
(e.g. GUI and motorized MIDI control), the current state of a Parameter must
be sent to all listeners when that state changes.

   "A Parameter can have multiple listeners, which are notified upon state
   changes."

When we discussed saving/restoring state, the issue of compatibility came
up.  A reasonable solution was to allow for hidden Parameters which retained
compatibility with older plugin versions.

   "Parameters must identify themselves as hidden or visible."

When saving and restoring state, the majority of the state of the majority of
plugins can be represented by taking a snapshot of the state of all
Parameters.  Sometimes, however, it is useful to save and restore opaque
blobs of data (e.g. Parameters which have an ordering dependency, data
which does not map well onto Parameters).  Therefore, saving and restoring
of plugin state involves Stata.  Generally, a Statum will correspond to a
Parameter, but a Statum may be also be a blob of opaque data.  Not all
Parameters will have associated Stata, and therefore will not be saved with
the Plugin state.

   "Saving and restoring plugin state is done with Stata."



These abstractions seem to solve all the problems that I have seen arise.
This explanation is more conceptual than code-oriented, and certainly some
of this would not go through to code as is.

Thoughts?  Did I miss any issues? (**)

Tim


** There were two thoughts that came up that I am not sure have a mapping in
my model.  One was the idea that vector parameters are different than scalar
parameters.  Can anyone expound?  The other idea was that 'Controls' and
'Parameters' are different.  I've kind of addressed that via Control-Inputs.
Did I get it right?

T


-- 
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: