[gmpi] Re: Decision Time: 7.1.2
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 12 Jun 2003 13:07:23 -0700
> The profiles suggestion sounds like it neatly sidesteps the issue anyway.
Can you please explain to me how you come to this? I don't see how
'profiles' is any different than plug-global IO datatyping. It has a new
name - 'profiles' - which helps users understand, but forces plugin
developers to categorize (and thereby limit) potential uses.
I', looking for clarification - maybe I missed something?
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.
In other words:
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,
supporting multiple enum values in a host complicates host
implementation significantly. Further, the set of appropriate enum
values will vary based on platform and application type, i.e. some
will be rarely used on certain platforms, so supporting the full set
of enum values will be difficult to justify from a cost/return basis,
so it will be rare for a host to support all the enum values, so full
interoperability of GMPI X.Y (for any X and Y) plugs and hosts is
unlikely. If not handled carefully, that nontrivial compatibility
matrix characteristic is likely to produce a significant customer
satisfaction problem. And for plug and host developers, as has been
pointed out recently, the choice issues are nontrivial.
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
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
Other related posts:
