[gmpi] Re: Where are we?: 7.1.2/Untangling issues
- From: "B.J. Buchalter" <bj@xxxxxxxxxx>
- To: "gmpi@xxxxxxxxxxxxx" <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 17 Jun 2003 23:44:08 -0400
>> 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
Agree, but I would point out that it is not really 16 bit/24 bit int. It is
really machine word sized fixed, so 16/32 on 32 bit processors (with 24 bit
represented as 24 bit packed into 32 bit), and 24 bit word size fixed on
processors like the DSP56k series (where 24 bit is the largest native word
size [or 48 bit wide dual memory accesses -- this is, in fact, the format
that Sonic Studio uses]). So it seems to me that that the native fixed and
float word sizes are appropriate per platform -- eg. 24 bit is appropriate
for DSP56k but not for PPC or x86, where 32 bit fixed is appropriate. The
different appropriate word sizes are different for different architectures,
and IMHO it does not make sense for GMPI to support a non-native format. So,
that being said:
For modern float architectures (PPC, x86, MIPS, ARM?):
Float32
Float64
VectorFloat (e.g. With current architectures, Float32 with alignment
guarantees. Please note that with current architectures, Float64 precludes
the direct use of vector units!!!!)
For esoteric float/fixed architectures (SHARC):
Float32
Float40
Fixed16 (less interesting)
Fixed32
For fixed architectures (DSP56k):
Fixed24
Fixed48
For 16-bit fixed architectures (ADSP21xx, BlackFin, others):
Fixed16
Fixed32 (accumulator precision)
Please note that the types listed above are Fixed -- not Int.
>
>> 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?
>
Probably not. It seems like it would make more sense to have multiple
subgraphs, each running with the proper type (e.g. The modular synth hosts
Float64 modules, but is itself a Float32 plug -- if the Float64 proves to be
required [if there is feedback, our tests would indicate that it is
required].
>
>> 4 - For each of the areas GMPI is intended to address, are multiple
>> sample data type pins per plug required?
>
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?
>
Yes -- these types need to be specified per architecture. This should be
pretty obvious, and easily extensible for new ports. It needs to be
restricted to the native types for the architecture -- all others are cruft
(great word). Each architecture should have one mandated I/O type (eg
Float32 on PPC/x86, Float32 on SHARC, Fixed24 on DSP56k). Other types should
be optional in both hosts and plugs. The host is required to define the type
for the graph. Multiple (different typed) subgraphs can be controlled and
maintained by the host or by a hosting plug that runs with one I/O type and
uses a different I/O type for its internal subgraph.
>> 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?)
See above. Each architecture needs to have a cannonical type and well
defined supported types. Some architectures may need to have more than one
cannonical type (e.g. For SHARC both fixed32 and Float32 are cannonical).
Use of the non-cannonical types must be negotiated.
>>
>> 7 - If the answer to 5 is No, then what, if any, mechanism outside of
>> the official documents is needed to handle the situation?
>
Needs to be enumerated in detail.
Best regards,
B.J. Buchalter
Metric Halo
M/S 601 - Building 8
Castle Point Campus
Castle Point, NY 12511-0601 USA
tel +1 845 831-8600
fax +1 603 250-2451
If you haven't heard ChannelStrip yet, you don't know what you're missing!
Check out SpectraFoo, ChannelStrip and Mobile I/O at http://www.mhlabs.com/
Download a 12 day demo from <http://www.mhlabs.com/demo/>
----------------------------------------------------------------------
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:
