[gmpi] Re: 3.12 wrap-up

> Something that does matter (I think), is that it says that the host is
> responsible for doing the mapping. I'm just wondering: won't there be
cases
> where it would make more sense for the receiving plugin to do decide on
the
> mapping depending on what it is receiving from?

Hi Koen,
My preference is no.  If my plugin has a parameter that ranges from (for
example) 0 to 10, then that's what i want to receive.
  I don't want to recieve different range and have to map it myself.  I
don't want to have to write a bunch of if-else statements to handle
conversions from any arbitary type either.

I would prefer the conversion to be external.  SynthEdit handles this type
of thing via seperate plugins.  i.e. there is a "Float to Bool" plugin, and
a "Float to Text" plugin, which has options like "Number of Decimal Places".

The fact is, conversions are rare, and when you do need to convert, it's
nice to have a pre-written object with plenty of options.

My feeling is that the need to convert parameter types is more relevant in
modular hosts anyhow, and not really a concern for the mainstream.

Best Regards,
Jeff


----- Original Message ----- 
From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Thursday, May 20, 2004 8:43 AM
Subject: [gmpi] Re: 3.12 wrap-up


> On Wednesday, May 19, 2004 9:04 AM [GMT+1=CET],
> Tim Hockin <xxxthockin@xxxxxxxxxxxxx> wrote:
>
> > On Tue, May 18, 2004 at 11:12:45PM -0700, Chris Grigg wrote:
> >>> Section 3.12 up for review - wrap up time.
> >>>
> >>> http://www.gmpi-plugins.org/gmpi/requirements.php#sec_3.12
> >>>
> >>> If you have problems, speak now...
> >>
> >> It's fine, but I don't understand why you took out that part that
> >> clarifies that normalization isn't expected for non-continuous types.
> >> "Appropriate" seems too ambiguous to do the job.
> >
> > Well, firstly I disagree that it's only continuous.  It's probably OK to
> > map to enum types, if we define consistent rules.
> >
> >> I think in general there's a lot of loss of precision between the
> >> discussions here and the summaries that go into the document.
> >> Shorter's not always better.
> >
> > A lot of the details I drop are accidental.  In this case, I didn't
think
> > that was right for requirements.  Requirement SHOULD be simple.  Too
often
> > we're dictating implementation details.  The requirement is really that
> > outs map to ins.  Details are left for later.  If there is something we
> > need to explicitly allow or disallow for a reason, then it should be in
> > here.  Mandating "only continuous controls" is arbitrary, at this point.
>
> Something that does matter (I think), is that it says that the host is
> responsible for doing the mapping. I'm just wondering: won't there be
cases
> where it would make more sense for the receiving plugin to do decide on
the
> mapping depending on what it is receiving from? I'm not saying it is, just
> asking if maybe people feel the need to be able to overrule the hosts
> mapping when it is necessary.
> [I'm not sure (at all), but isn't it so that in Audio Unit world, there
are
> a bunch of predefined types of mappings and the developer of the plugin
can
> specify his/her(?) own mappings if needed?]
> I can't think of something immediately, but if anyone thinks this should
be
> possible, it should be in the reqs right. So, I'm asking to be sure...
>
> Koen
>
>
>
> ----------------------------------------------------------------------
> 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
>
>



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