[gmpi] Re: Reqs TODO

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 26 Nov 2003 11:43:12 -0800

On Thu, Nov 27, 2003 at 11:46:38AM +1300, Jeff McClintock wrote:
> Optional sample type via header file?, YES.  Will allow integer types as
> well (yes, integer sample format has been requested several times by several
> people on this list, can't ignore it).

> My host for example will support 32 bit float and nothing else. Yours?,
> that's up to you, if you wish to provide 64bit, call it a competitive
> advantage.

So your host won't handle some plugins.  We're back to square one.

One of the MAJOR goals of GMPI as I see it is the knowledge that a plugin
coder does not need to 'handle' different hosts.

Now, we can either pick ONE FORMAT FOR ALL AUDIO, or we can pick to support
multiple formats at once (profiles are different - see below).

1) If we pick one audio datatype, we have to live withit until we change it.
If we decide to change it, it is changed FOR ALL PLUGINS.  In otherwords
GMPI v1 is float32, but GMPI v2 is float64.  Even this incurs the cost of
supporting two datatypes (see #2)

2) If we support multiple formats, we have to make it doable for ALL
HOSTS.  All plugins indicate what type of IO they want to do (globally or
maybe per-stream).
        a) Provide a set of float32<->float64 wrappers which load type X
           plugins into type Y hosts and converts before and after the plugin
           (so the host is oblivious, and only supports one datatype).
           Connecting an X to an X in a Y host would involve Y->X->Y->X->Y
           conversion.
        b) Provide an SDK based API to convert between types so the host can
           do the same thing as option a, but only when it is NEEDED.
           Connecting an X to an X in a Y host would involve Y->X->Y
           conversion.
        c) Mandate that hosts do it themselves.

I like the idea that all plugins JUST WORK, and none of this is an issue,
but I know that the day will come when f64 is reality.  I could live with
something like 2b.  IFF we all agree that the cost is worth it.


On profiles:  Profiles are supposed to define the platform characteristics.
That just happens to include sample type.  A host does not load multiple
profiles, or if it does, it is just doing the above option 2c.  I'd rather
see 2b than that.

I think we should disregard profiles for now, and get the first GMPI designs
roughed out.  THEN we can look at the design and decide what needs to be
'profiled' and handle it then.

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