[gmpi] Re: Decision Time: 7.1.2
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 12 Jun 2003 14:48:13 -0700 (PDT)
First, this Profiles discussion is OT. We're supposed to be gathering
Requirements, yes?
The requirement comes down to a much simpler question: Do we support
multiple datatypes? If we agree that YES we do, then we eventually need to
decide how.
However, Profiles have more potential applications, too.
> You're right, from the perspective of a plug-in developer who's only
> targeting one market, like DAWs, there is no net difference. The
> benefit is that profiles allow the same basic GMPI architecture to be
> used in multiple applications and markets, while keeping the
> technical requirements of each individual market out of the way of
> all the other markets.
This is not specific to profiles, of course.
> If there were some per-plug or per-audio-pin enum property for sample
> datatype, and no profiles, then any GMPI plug-in could use any enum
> value (or maybe set of enum values, depending). That plug could only
> be used in hosts that support the set of enums it uses. However,
> Whereas, if there were some per-plug or per-audio-pin enum property
> for sample datatype, and profiles -were- used, then each GMPI
> plug-ins would be written with one or more profiles in mind, and
> could use -only- the enum values permitted by those profiles. That
The argument sounds nice, but is misrepresented, I think. It's no more
difficult or less difficult with either method. If the host has to support
more than one profile, it is the same as the host supporting more than one
datatype. If a Plugin is written with one profile in mind, it only has one
datatype.
It makes a lot of sense to me to say "When you buy plugin X, you get the
Float32, Float64, AND Int24 versions in one package! Compare that to
competitor Y who only gives you Float32."
Whereas profiles assume some a priori knowledge about where Int24 is useful.
If I have a very full-featured host, I shouldn't need to declare that I
support 'Mobile Audio' profiles just to get Int24 support.
We're saying the same answer, just different words, I think. Am I wrong?
Our requirement then is: Plugins have single I/O datatype for all inputs
and outputs. How it is done is not yet important, I think.
Now gete everyone to agree to that requirement.
Tim
> plug could only be used in hosts that support any of those same
> profiles (typically a host would support only one or two profiles --
> maybe just float32 and float64 in the case of DAWs), and since the
> number of enum values allowed by a given profile is small (in the
> optimal case, just one), host implementation is significantly
> simplified. Full interoperability of plugs and hosts within a given
> profile is guaranteed, improving customer satisfaction. And focuses
> target platform choices for developers.
>
> -- Chris G.
>
> ----------------------------------------------------------------------
> 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
>
----------------------------------------------------------------------
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:
