[gmpi] Re: Decision Time: 7.1.2

> >Agreed, and I think we're slowly heading that way - still a lot of people
> >who feel JUST Float32 is enough, and I think the evidence is mounting that
> >it ISN'T enough to reach all our goals.
> 
> I happen to find that view persuasive, although the UV22/SACD 
> encoding example is causing me to reconsider, but also think it 

How so (reconsidering)?  I began the conversation wanting Float32 hardcoded,
fixed.  Period.  Then I realized that some systems will need int, or will
not work.  Then I realized that if we don't accommodate Float64 NOW it will
be pain LATER.  So I've arrived at my position that a single plug-global
datatype is the right mix of simple and flexible.

> >I don't think we should talk about WHICH types will be supported just yet.
> >Just that we agree to support more than one hardcoded type.
> 
> Again, is there really support for that?

The hand-held argument basically mandates it.  Call me extermist, but it
seems that we either support 1 hardcoded, fixed, assumed type for ALL I/O or
we have some flexibility and allow different types at some level.  I'd argue
that level is the plug level.

> >WRT a: If we do anything outside of a single hardcoded, a priori type, the
> >host has the same complexity as a per-plug type.  The host must recognize
> >that a plugin is NOT the right {profile, datatype} and either reject it or
> >wrap/convert it.  Is that a correct statement?
> 
> Seems like it would depend.  Maybe I haven't said it clearly enough, 
> but I have been thinking that a host would be written to a specific 
> profile, so all it has to do at plug load time is look for the 
> matching profile identifier, rejecting anything that doesn't match. 

Great!  If I read correctlty, we DID just say the same thing.  

        if (plug.profile != host.profile)
                reject_plug();


And I'd prefer to add to the top:

        #define profile datatype

> >Well, as a pseudo standards body (imagine if POSIX let just anyone who was
> >interested join ;)...
> 
> The MMA is a real standards body, FWIW.

I meant US as a working group ;)  Of course MMA is a real standards body :)

> I agree that it seems impossible to reach agreement on a single 
> sample data type that meets all the needs we have been charged with 
> meeting, and that that means the only way to go (short of changing 
> scope) is some form of parameterization.  Where you and I currently 
> seem not to agree is whether there are any significant differences 
> between having a single, wide, global parameterization space, 
> vs.multiple, narrow, domain-specific parameterization spaces.

Yes.  So far the ONLY parameterization space is datatype.  I haven't seen
how any other parametric variable can be directly associated.  We haven't
talked about that, much.

> (Personally I'm not sure it'd be the end of the world if plugs of 
> profile X couldn't even -run- in hosts of profile Y, as per binary 
> differences, but then again others might feel differently.)

I feel differently.  I think that GMP{I plugs should be as common as
possible to each other (wrt API).

> Profiles define markets, and what I'm saying is that the more 
> narrowly drawn a profile is, the less room there is for that kind of 
> fragmentation to exist, and therefore the more efficiently each 
> market can run.

I think I see the reasoning, and I believe that defining markets in an API
is foolish.

> >This is why I think you and I are saying the same thing, we just have
> >different Big Picture words.  I find the idea of profiles to be imposing
> >some arbitrary idea of usage on plugins and hosts, when what really differs
> >is datatype.
> 
> a) We already agreed there could be other things in a profile, so I'm 
> not sure I understand what you mean here.

I have seen no argument for how other variables tie together...?

> b) Just because something is arbitrary and an imposition doesn't mean 
> you're free to ignore it, i.e. sometimes initially more-or-less 
> arbitrary choices acquire an essentially immovable character as a 
> result of development practices and codebase evolution -- for example 

So why should we arbitrarily decide that all Mobile devices use Int?

> use of float32 per existing VST plugs.  Profiles are a mechanism for 
> encapsulating these existing practices.  The purpose is not to impose 
> anything unwanted on the developer... I can't think of anything that 

This is a very good summary - I like that.  Let me ask this:  do you
envision codifying a profile as "Workstation" which assumes the answer to
all params, or as a tuple of the answers to all params?

> a) If a given developer doesn't believe in the dogma, s/he can just 
> go beyond it and write some new reality.  If you don't think there 
> should be any dogma, why are you participating in the creation of a 
> standard?  8-)  Standards are for defining interoperability 
> baselines, and if well-designed they should almost never limit 
> maximum functionality.

Now I don't follow - all a profile does is impose restrictions - arbitrary
restrictions.  It is telling developers that YOU know better than THEM what
their market is: what it is called, what datatype it wants, etc.

All I'm saying is that we CAN'T.  Let's define the minimum number of 
parameters.  Let's give them sane defaults.  Let's eliminate as much need
for negotiating as possible.  Let's let the plugin developers decide what
makes sense.

> b) Any standard open enough to include any arbitrary extension is 
> necessarily going to impose inefficiencies in the form of framework 
> complexity and perhaps runtime performance. (...I think there some 

I'm not proposing arbitrary extension.  I hope that my case did not come
across that way.  I am proposing that we have a fixed number of GMPI
datatypes (isomorphic to a fixed number of profiles).  When coding, the
plugin developer chooses which of those types the plugin uses (isomorphic to
self-classifying in a profile).  We are arguing the same thing, with
different words.  The only difference is that you would lump several
variables together and I would not.

> framework complexity issues.  So there does not seems to be any 
> consensus that supporting completely general-case mixes is worth its 
> cost.  Profiles allow this to be focused down to cases.

Again, we're not arguing anything different.  A developer has to pick a
profile to declare their plug.  This defines their I/O datatype.  It is the
very same as the developer picking their datatype.

> c) Again, please provide some more motivation for why you would want 
> to use a "Mobile" plug-in in your DAW host.  I don't understand what 
> your use case is.

I find anything that tells me that I CAN NOT do something because of some
arbitrary decision to be a mistake.  It's a limit, and not a necessary one.

> >I was under the impression that ProTools does some Int24 stuff, no?
> 
> Please forgive my choice of an insufficiently outrageous example. 
> Pretend I said int8 or int16 instead.

I don't think we need to support those.  Is it really outrageous to conceive
of an simple Int24 based music product for use on a workstation?  Does that
product need to declare itself as a Mobile host, to load Int24 plugins?

> Tim, please re-read what I wrote.  Specs structure, maintenance, 
> evolution process, etc.  There's more to this than programming.

I really don't see how profiles make any of this BETTER.  Different, but no
better. And in some cases, worse, I say.  It imposes a limit that YOU not
the developer decides.

> >Once we agree to support more than one hardcoded type, we may as well
> >support N types (I started as a database guy - the only numbers that exist
> >are 0, 1, and N).
> 
> I respectfully disagree with this analysis in this case.  What you 
> say is true at the framework level only and disregards the actual 
> work load for the developer.  Having a small multiple vs. having an 
> unbounded multiple makes a huge difference in terms of the matrix of 
> interoperability conversion cases that a developer needs to decide 
> whether or not to do the work to cover: ((N^^2)-N).

I think I am not clear:  I don't mean that any plugin can use ANY datatype,
and the host needs to support them all.  as GMPI, we define the available
GMPI types:

        typedef enum GMPI_datatype {
                GMPI_FLOAT32,
                GMPI_INT24,
                GMPI_FLOAT64, /* one day */
        };

When a developer writes his plugin, he declares one:

        GMPI_descriptor *myplug;
        /* other stuff... */
        myplug->datatype = GMPI_FLOAT32; /* I always get Float32 buffers */

> >We can define N profiles or N datatypes.  The GMPI API
> >needs to have a parameter somewhere of which {profile,type} a given plugin 
> >is.
> 
> More like, a plug has a list of 1 or more profile identifiers, and a 
> host has a list of 1 or more profile identifiers.  When there is 
> overlap, that plug can run in that host; otherwise, not.

May I change a few words in your statement, which will show you my
preference?

> More like, a plug has 1 datatype identifier, and a 
> host has a list of 1 or more datatype identifiers.  When there is 
> overlap, that plug can run in that host; otherwise, not.

Am I clearer?  Maybe email is the wrong medium.  Can I convince people to
get on IRC some time to discuss this with less latency?


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