> Not ant once, I think its better to specify a profile where the What if I _WANT_ to support Float32 and Float64? > Those would not interoperate (why would you want them to) and could be two You're making policy decisions in an API - bad bad bad news. > completly seperate SDKs, though they might only vary in the typedef > gmpi_sample line of gmpi.h. ACK!! Now we have two SDKs? This is getting really far from what I perceive as sane. Maybe I need to go have a sleep on it. > > > (or Alitvec and SSE if you want it at that granularity) plugins use the > > > float profile, ARM uses int24. This could tie up the binary compatibility > > > issue on multi platform OSs to. > > > > I'm sorry to say this: GAG! We are the WRONG people to make decisions like > > this. > > Um, sorry? Who else is going to make it? I dont think there are any people > on the planet more qualified to decide what makes a good and efficient sample > representation for realtime audio than audio plugin devleopers. We can make THAt decision (well, maybe we are actually incapable, but..). We SHOULD NOT make the decision as to "All x86 uses Float32 and all Arm uses Int24". First of all, we then need to enumerate EVERY platform we expect to run on. Second of all, there are x86 systems that SUCK at FPU, just as an example of how architecture CAN'T have anything to do with profile. Architecture SHOULD NOT come into this discussion. > But we dont need to support more than one _at the same time_, and there is I think you're really saying we don't need to supoprt more than one datatype/profile on any single platform. Is that a correct interpretation? > But in the case of mobile and desktop use there are exact fits, int24 and > float. And what of x86 palmtops or x86 webpads? What of other CPUs that are used in (for example) game systems and palmtops and other? MIPS, for example, traditionally has an FPU that is optional. Do we now have to decide the best profiles per chipset? I'd like to understand, and profiles didn't seem too far gone, until architectures came into play. ---------------------------------------------------------------------- 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