[gmpi] Re: 3.11 Parameters

On Tue, Mar 30, 2004 at 08:13:10PM -0700, Mike Berry wrote:
> Req 50: Why do we need boolean separate from integer? Can't bool just be 
> int with a range of 0 to 1?

As long as we differentiate an intended boolean value (ie, a button) from
any other integer, I'd say that is fine.  The actual implementation of
parameters may have "hints", in which case an int primitive with a bool hint
is sufficient.  All the requirement is is that GMPI provide the type.  NO
implementation details, yet.  Should I add something like that to the "More
on.." link?

> Req 52: Are parameters that are not safe for real-time automatable?

I'd say that is up to the host to decide.  If you automate or twiddle an
non-safe knob, you might get dropouts...

Or should those even be parameters?  What parameters will be marked as
not-safe for RT use?

> - Can we have a way for a parameter to reveal its linkages to other 
> parameters? I.e., if the host changes parameter 2, parameters 4 and 5 
> may change?

This could get complex, especially if you want to expose anything more than
simple relationships.  If a change to A causes a change to B and C, do we
express the actual relationship of values?  Or is a tree-like thing which
indicates the relationship of B and C as children of A enough?  Can B and C
be changed independantly of A?

Can you give us real-worldish examples of why this is useful, and how it
would be used?

I think we DO need to support the plugin changing a parameter on its own (as
a result of another param change, or spontaneously (like an LFO).

In fact, I'd like to add that as a requirement.  Arguments?

> - Can the parameter list change during runtime (please say no)? Can 
> hidden/not hidden change during runtime (also no)?

Well, I don't necessarily think the parameter list needs to change, but I do
think there needs to be some dynamics to plugin structure.

What I have talked about before is a sub-plugin structure (I'm so bad with
naming, let's call it a "module" for now).  The plugin defines N module
classes.  Each module class has some parameters and/or some I/O.  A running
plugin can have any combination of modules active at a time (subject to the
plugin's whims).

Prototypical example: a mixer plugin.  It defines a set of modules:

MONO:   1 input, 3 EQ params, a gain param, a pan param
STEREO: 2 inputs, 3 EQ params, a gain param, a balance param
BUS: 2 outputs, a gain param, a balance param

The plugin could have 16 MONO modules and 1 BUS module.  Or it could have 64
STEREO modules, 8 MONO modules, and 4 BUS modules.  All the parameters (and
their types, limits, etc) and all the IOs are know at plugin instantiation
time, but the actual structure of them is flexible.  Does that make any
sense?

----------------------------------------------------------------------
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: