[gmpi] Re: Where are we?: 7.1.2/Untangling issues
- From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 17 Jun 2003 21:06:27 -0400
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
