[gmpi] Re: Where are we?: 7.1.2/Untangling issues

See my responses below.

===========================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
Silence, a language for programming music and sound
Available at http://www.csounds.com
===========================================


----- Original Message ----- 
From: "Chris Grigg" <gmpi-public@xxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Monday, June 16, 2003 11:12 PM
Subject: [gmpi] Re: Where are we?: 7.1.2/Untangling issues


> More info is needed to proceed, but too many issues are tangled at 
> the moment.  So I suggest splitting the requirements collection into 
> the constituent parts we've been arguing about, but this time with 
> consideration for all the different areas GMPI is supposed to address 
> (there's more than just DAW and mobile in the list), before anyone 
> jumps to the solutions.    Jumping to the solutions is what's been 
> stopping us.
> 
> -- Chris G.
> 
> -----------------------------------
> 
> 1 - For each of the areas GMPI is intended to address, what sample 
> data types are currently appropriate?  (Make no attempt to reduce the 
> set, just list them.)

16 bit int, 24 bit int, 32 bit float, 64 bit float

> 2 - For each of the areas GMPI is intended to address, what sample 
> data types are reasonably foreseeable in the next (say) four years? 
> (Make no attempt to reduce the set, just list them.)

Exactly the same

> 3 - For each of the areas GMPI is intended to address, are multiple 
> sample data types within a single graph required?

Different shapes and rates, yes; different size samples, no.

> 4 - For each of the areas GMPI is intended to address, are multiple 
> sample data type pins per plug required?

Different shapes and rates, yes; different size samples, no.

> 5 - In the (likely) event that the set of areas GMPI is intended to 
> address has sufficiently different data type requirements as to make 
> supporting all of them too cumbersome or expensive (in the opinion of 
> enough developers), is it necessary to do anything in the official 
> documents to keep any of the areas separated from the other, for 
> either technical or marketing or other reasons?

No.

> 6 - If the answer to 5 is Yes, then how, exactly, should the official 
> documents achieve this separation?  (E.g., with technical API-level 
> measures?; with technical option(parameter)-limiting measures?; with 
> industry-consensus or market mechanisms?; on a per-project basis?; or 
> through some combination of these?)
> 
> 7 - If the answer to 5 is No, then what, if any, mechanism outside of 
> the official documents is needed to handle the situation?

Shouldn't be any.

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