[gmpi] Re: Where are we?: 7.1.2

> We argued long and hard on this last week.  If you didn't follow, please
> read the archives.

Hi Tim,
I did read, I think I was't clear. I was agreeing with you, one datatype at
a time is reasonable.

> D) One global hardcoded datatype
> E) One datatype per profile, limited number of profiles

My main point is, from the plugin's point-of-view.  Enforcing a single
datatype, or enforcing a profile, is exactly the same thing (one datatype
per plugin).

I'm not against profiles.

I'm just saying, you are adding an unnessesary layer of abstraction.
Profile=datatype.  Why complicate it.

Jeff



----- Original Message ----- 
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, June 17, 2003 11:46 AM
Subject: [gmpi] Re: Where are we?: 7.1.2


> > > Let me ask this:  Does ANYONE feel it is necessary to support more
than
> > one
> > > datatype in the graph at one time?
> >
> > Sounds reasonable.
>
> I didn't ask if it was reasonable - is it NECESSARY?
>
> > Is a "Profile" just an extra layer of abstraction?, are we really
talking
> > about "Datatypes"?
>
> I suggest you read the heated debate between myself and Chris and others.
I
> was saying EXACTLY the same thing.
>
> > Profiles arn't a bad idea, a device to aid compatiblity by saying: "one
> > datatype per plugin", "one datatype per host".
>
> Something like profiles (I dislike the name, but the idea might be OK) is
> bigger.  See below
>
> >    In practice though, you can't force "one datatype" on a host writer.
> > Just as some software supports both VST and DXi, some may choose to
support
> > both GMPI32 and GMPI64.
>
> If we provide GMPI32 and GMPI64 then (realistically) all hosts HAVE to
> support both.  If they don't, they are less competitive.  Suddenly users
ask
> "why doesn't your host support my 64 bit plugins?".  We then force the
> complexity on them just to keep up with the Joneses.  Even though tests
> show that 64 bit DOESN'T matter.
>
> Now, if you have a test that shows 64 bit I/O making a difference, bring
it
> forth.  Now is the time.
>
> Profiles allow us to support more than one type, but to make the
seperation
> wide enough to NOT cause this conflict.  One thing we haven't established
is
> whether there is a single Int type that is correct for all handhelds.  Is
it
> Int24 or Int16 or other?  If we can't boil that down to a single type
(like
> we can with Float32) then we're in a quagmire again.
>
> > Are there really only two choices?
> >
> > A) Datatype specified at Plugin level.
> > B) Datatype specified per pin. (e.g. float-in, double out possible)
>
> No, there are a multitude of choices, but not all of them make sense :)
>
> To that list I'd add
>
> C) Datatype per context (inputs vs. outputs, or plug defined)
> D) One global hardcoded datatype
> E) One datatype per profile, limited number of profiles
>
> We're more or less arguing (A|B|C) vs E.  D is ruled out by the agreement
to
> support handhelds (unless we renig on that, which is still an option).
>
> We argued long and hard on this last week.  If you didn't follow, please
> read the archives.
>
> Tim
>
> ----------------------------------------------------------------------
> 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: