[gmpi] Re: 8a.0 What is a Parameter?
- From: Marc Poirier <fipnid@xxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 7 Aug 2003 15:09:24 -0700 (PDT)
--- Tim Hockin <thockin@xxxxxxxxxx> wrote:
> > 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.
I never questioned your motives or described you as "power-hungry" or
anything like that. But you were, whether you meant to or not, doing
things that elevate your perceived authority in the group. And my guess
is that you didn't realize this, hence I brought it up. Most folks aren't
too conscious of group dynamics, I've found, so I'm not chewing you out,
just trying to make you (and maybe others) more aware...
> 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.
Oh, okay, that seems sensible to me, personally I can't think of any
reason to not allow the parameter-restoring order to be irrelevant.
> > 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
Well, your idea is interesting, but it seems to me quite complicated, with
no advantage that is apparent to me. But I feel like maybe I'm missing
something. Maybe you could provide a real-world example, showing that
this isn't as over-complex as it seems to me to be, and why it's a useful
structure? Or maybe everyone else gets it and I'm just being dim (which
is rather likely)...
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:
