[gmpi] Re: Decision Time: 7.1.2
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 11 Jun 2003 17:06:49 +1200
I havn't heard strong reasons for using 64 bits for audio.
My understanding is that 16 bit int is OK (CDs use it).... 24 bit integer
is wonderfull..... 32 bit float is even better (soothes the most rabid
audiophile).
64 bit is needed for filter coefficients, but that happens *inside* your
plugin.
Ron suggested a modular system might go "low-level" and pass filter
coefficients between plugins. I suggest this is "sub-modular" processing.
My reasoning: Sub-modular synths, like SyncC modular, where you design
your own filters, also support single-sample audio feedback (to make IIR
Filters). Single-sample processing is beyond GMPI, therefore double
precision comunication is also out of scope.
What about 24 bit integer samples (card-based DSP). Mayby that is more
relevant? If so, do we go the whole hog, and make sample format negotiable?
(float, double, int).....
To summarize:
*single precision float is cool.
*double precision is used in hard-core modular synths, but so is
single-sample processing, I suggest both these are out of scope.
*24 bit integers are here now, used in card-based DSP.
My life is MUCH easier with single precision floats only...... But to be
realistic, mayby this needs to be enumerated/negotiated......same as
interleaved/not.
>Process32() and Process64().
I don't like this approach, as it's not extensible. An enumerated type would
be easier?
As before, I expect most of us to live in the 32 bit float world. The
double-precision and 24 bit crowd would play in their own sandpit, happy in
the knowledge that 80% of their code and investment is transportable to the
mainstream.
I absolutely arn't going to code for all three cases in each plugin i write.
As far as bugs go... that's a freaking cockroach sandwich.....
Best Regards,
Jeff
----- Original Message -----
From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, June 11, 2003 8:54 AM
Subject: [gmpi] Re: Decision Time: 7.1.2
> > (g). Plugins have 2 process calls, Process32() and Process64(). By
> >default in the GMPI headers, Process64() maps directly to Process32 with
> >casting back and forth. Plugins who wish to override/supply their own
> >Process64 routine can do so. Plugins who do not wish to do so can simply
> >implement Process32, and 64 bit will be transparently handled for both
> >the host and plugin.
>
> before discussing how to support 64 bit data flow between plugins, it
> first needs to be established that there are worthwile benefits from
> doing so. the best i've seen so far has been ron's point about
> building modular synths out of GMPI plugins, which was somewhat
> countered by steve's observations based on LADSPA.
>
> otoh, i sort of like this proposal. the problem with it is that a
> plugin author will spend a non-trivial amount of time on two different
> versions of their code, which may be rendered wasted by the decision
> of most hosts to support only one format. even so, it does have merit
> as a very agnostic policy.
>
> please just don't suggest Process32Interleaved() and its couins :))
----------------------------------------------------------------------
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:
