[gmpi] Re: 8a.0 What is a Parameter?

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 7 Aug 2003 14:29:43 -0700 (PDT)

> >  From Tim:
> 
> Just to start with, I *really* don't like a "facilitator" starting a topic
> with answers, rather than just questions (particuarly answers for the
> entire topic, and then saying that we should only deal with the first
> sub-topic, yeesh).  In the future, please consider this and not abuse your
> role by trying to excert more power and domination over the process than
> you should.

Typically, I don't answer for a few days.  I figured that this list would
grow and change, so the first few days would be pretty free form discussion.
But it's NOT about power.  If you think ANYTHING done here is about power or
recognition, you need to step back and rethink.  I'm here cuz I have an
interest, both technically and socially, in the project.  No one pays me for
this.  I do it for fun, please don't question my motives by suggesting I am
some sort of power-hungry leader.  Conversly, I respect the opinions of the
group to such a degree that I gave up my own project (XAP) in order to work
on GMPI.

> > * Parameters must be independant of each other.
> 
> I think that these are both totally vague statements, and the discussion
> of this point should begin with someone saying what inter-parameter
> dependencies and a general concept of its implementation.  If no one has
> such desires, then I guess that means that parameters will be independent,
> which may be fine.  But I have a feeling that Koen might have more to say
> about this...  ;-)

What I meant was that if I save and restore parameters, the order in which I
restore them should not matter.  If setting A changes B, then I must restore
them in a specific order.

> nesting.  Parameters descriptions can indicate that a parameter is a
> member of a clump by specifying a clump ID, and then the plugin can supply
> a list of clump IDs with names for each clump.  This allows for the
> possibility of much better generic interfacing to the plugin (like
> providing parameter list with well-organized sub-menus, arranging
> parameters in logical groups in a generic GUI, etc.).

I like this, but I still like my sub-units (modules?) idea.

So in my mind I see
 Plugins -- which contain
    Parameters
    Modules -- which contain
      Parameters
      ParamGroups (clumps?) -- which contain
        Parameters


Perhaps tehre is some clever isa relationship there.

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