[gmpi] Re: Decision Time: 7.1.2
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 12 Jun 2003 16:58:59 -0700
Tim said:
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.
Tim, I respectfully disagree that the issue of profiles is OT to the
issue of what sample data types will be supported. It's still all
about requirements.
Your question as proposed is stated so as to imply a single,
monolithic, pan-GMPI approach, and as a result would force everybody
else to treat the issue in terms like float32 vs float64 across all
of GMPI, making it a critical fundamental technology choice, and
therefore necessarily a much more charged and contentious choice...
but because of our earlier scope decision (including mobile etc.) I
doubt we will be any more able to reach agreement than we have been
to date -- doomed to fail since, as we've seen, one size simply does
not fit all.
Whereas something along the lines of the profiles idea would make it
possible to manage those choices at a more granular level of the
community, which would simplify and de-escalate the decisions within
each profile, sidestepping the how-to-please-everyone-at-once
problem. This simultaneously makes it easier to make progress and
makes GMPI technically better on each specific platform/application.
If you want to jump to a group decision about sample data types
_specifically_ _for_ _DAW_ _applications_, and at the same time say
that we would like there to be some mechanism that allows other
markets (like mobile) to pick different sample data types, then I
would have no objection to that. (I vote for float32 for the time
being, with future options TBD at the appropriate times.)
If you want to jump to a group decision about whether a single
plug-in should be allowed to have audio pins of different sample data
types, then I have no objection to that either. (From what I've
heard, I vote for one sample data type per plug.)
But for the reasons stated earlier, I don't see how we can jump to a
group decision about what sample data types will be supported
globally without either a) making hosts unreasonably complicated and
inefficient, and risking market confusion; or b) breaking the earlier
scope decision. The other alternative is to incorporate something
like profiles into the sample data type requirement, to isolate each
market's unique technical requirements.
(It just occurred to me that I have been merely assuming it's obvious
that there could be an 'Experimental' or 'Kitchen Sink' profile for
research/avant-garde/academic uses, so that the people who really
want to could write stuff that works with absolutely any of the audio
sample data types. In case seeing that possibility helps any.)
Couple more questions/comments inserted below.
-- Chris G.
However, Profiles have more potential applications, too.
True. For example, they could help address the multichannel formats
issue. Did you have further ideas?
> 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.
Without profiles, or some moral equivalent thereof, how would the
technical requirements of each individual market be kept out of the
way of all the other markets?
> 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...
I would assume that in the vast majority of cases, especially the
most commercially important cases, only one profile would be
supported at a time. Likely in regular MIDI+Audio DAWs float 32
alone will be just fine for several years, then at some point float64
would be added, and then there would be two, and eventually float32
might get retired, so you're back to one again. Unless something
exotic and new comes along.
And even if it is no more or less difficult for DAW plug-in writers
(important yes, only one of our target audiences, remember) to use
profiles, again, please try to think bigger than just DAWs and
replacing VST, and try to think about the advantages of a long-term
stable outer architecture.
...If a Plugin is written with one profile in mind, it only has one datatype.
Well, that assumes the optimal case, but isn't this exactly what
people have been clamoring for? They want, for excellent reasons, to
have just one sample data type. Absent profiles, how would you do
that -and- support mobile in the same framework?
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."
a) That sounds like the too-many choices problem that Vincent
expressed so well, and assumes that hosts will go wild with different
sample data types inside the GMPI-for-DAWs world, winding up back at
a fragmented multi-format plug-in market, avoiding which is a major
goal.
b) Nothing about profiles prevents a vendor from selling
multi-profile bundles like you describe.
Whereas profiles assume some a priori knowledge about where Int24 is useful.
Exactly, and that's a good thing. The industry defines profiles
specifically to -formalize- its highly expert a priori knowledge
about what tech choices are appropriate for each platform class, or
area of application. Standardization is all about reducing/focusing
the scope of the solution space for each plug and host developer,
thus reducing risk. While keeping the whole thing under the same
GMPI umbrellla.
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.
This position assumes that having a single 'full-featured' GMPI host
would be a desirable thing and a good idea, which (given the range of
platforms and markets we're trying to encompass) I'm not so sure
about, either from a technical POV or a markets POV. I mean, what is
the use case for supporting int24 plugs in, for example, Digital
Performer? What is the use case in supporting float64 samples in,
for example, Mobile DLS instrument banks? What are some examples of
a single application where both of these formats would be needed ('a
complete generalized GMPI host" isn't a very satisfying answer), and
if there are any, are they common cases, or edge cases? "Different
jobs, different tools" would probably be my practicality-driven
answer.
We're saying the same answer, just different words, I think. Am I wrong?
Well, I surely wouldn't say you're wrong to want what you want, and
it's true that if you only look at the end result for DAW plug
authors the distinctions mostly resolve down to the same core
technical thing in the case of any given single plug... but we can't
forget that the problem GMPI is trying to solve takes a much bigger
view than that, and I do think the two visions have critical
practical differences in terms of requirements definitions, and the
community politics of spec development, and how we structure a
workable and maintainable spec, and how easy vs. tough we make it for
developers to maintain and extend their GMPI codebases in the long
run.
Our requirement then is: Plugins have single I/O datatype for all inputs
and outputs.
I previously asked whether anyone wants to argue in support of more
than one sample data type per plug, and so far nobody has. So me, I
still think just one sample data type per plug is OK.
How it is done is not yet important, I think.
i really, really wish I could agree, but since without profiles this
cascades out directly into deciding what the actual sample datatypes
for all of GMPI will be -- where agreement seems impossible -- it
seems we have to consider the 'how' as well.
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
----------------------------------------------------------------------
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:
