Hi Tim, i agree with what you say, except... > but I know that the day will come when f64 is reality. I strongly, strongly disagree. Yes, it's well proven that 64bit math makes a measurable difference in some DSP, namely recursive filters. So, internally, some plugins may benefit from 64bit processing. However, there is zero evidence that transferring sample data BETWEEN plugins at 64bit is any use at all (except to severely increase your memory bandwidth requirements). We should not base GIMPI on the assumption that "everyone is moving to 64bit audio". There IS a limit to human perception, there IS a limit to the dynamic range of any sound system due to thermal noise levels, it aint much more than 24 integer bits. 32 bit float already gives a nice 'comfort level'. GIMPI isn't a modular synth system, so we won't be streaming 64bit filter coefficients between plugins either. Best Regards, Jeff ----- Original Message ----- From: "Tim Hockin" <thockin@xxxxxxxxxx> To: <gmpi@xxxxxxxxxxxxx> Sent: Thursday, November 27, 2003 8:43 AM Subject: [gmpi] Re: Reqs TODO > On Thu, Nov 27, 2003 at 11:46:38AM +1300, Jeff McClintock wrote: > > Optional sample type via header file?, YES. Will allow integer types as > > well (yes, integer sample format has been requested several times by several > > people on this list, can't ignore it). > > > My host for example will support 32 bit float and nothing else. Yours?, > > that's up to you, if you wish to provide 64bit, call it a competitive > > advantage. > > So your host won't handle some plugins. We're back to square one. > > One of the MAJOR goals of GMPI as I see it is the knowledge that a plugin > coder does not need to 'handle' different hosts. > > Now, we can either pick ONE FORMAT FOR ALL AUDIO, or we can pick to support > multiple formats at once (profiles are different - see below). > > 1) If we pick one audio datatype, we have to live withit until we change it. > If we decide to change it, it is changed FOR ALL PLUGINS. In otherwords > GMPI v1 is float32, but GMPI v2 is float64. Even this incurs the cost of > supporting two datatypes (see #2) > > 2) If we support multiple formats, we have to make it doable for ALL > HOSTS. All plugins indicate what type of IO they want to do (globally or > maybe per-stream). > a) Provide a set of float32<->float64 wrappers which load type X > plugins into type Y hosts and converts before and after the plugin > (so the host is oblivious, and only supports one datatype). > Connecting an X to an X in a Y host would involve Y->X->Y->X->Y > conversion. > b) Provide an SDK based API to convert between types so the host can > do the same thing as option a, but only when it is NEEDED. > Connecting an X to an X in a Y host would involve Y->X->Y > conversion. > c) Mandate that hosts do it themselves. > > I like the idea that all plugins JUST WORK, and none of this is an issue, > but I know that the day will come when f64 is reality. I could live with > something like 2b. IFF we all agree that the cost is worth it. > > > On profiles: Profiles are supposed to define the platform characteristics. > That just happens to include sample type. A host does not load multiple > profiles, or if it does, it is just doing the above option 2c. I'd rather > see 2b than that. > > I think we should disregard profiles for now, and get the first GMPI designs > roughed out. THEN we can look at the design and decide what needs to be > 'profiled' and handle it then. > > ---------------------------------------------------------------------- > 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 > > > ---------------------------------------------------------------------- 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