-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-03 18:00, Charles Henry wrote:
Would you prefer to set the types at configure time through a file--or for example by adding a -DDOUBLE compiler flag? The affected locations of code defining the types could just use #ifdef DOUBLE
no, not at all.
In either case, the configure option seems necessary. It still seems an open question how best to offer the double-precision types to externals developers.
yes, of course this is the point. if the external includes (the "correct") m_pd.h, it should get the correct precision for free. right now, the default is to use 32bit. if you set the PD_FLOAT_PRECISION macro to 64 (e.g. by adding "-DPD_FLOAT_PRECISION=64" to the preprocessor-flags or by modifying m_pd.h), you will get a double precision build.
if you set CPPFLAGS, no external will be able to track the current precision. if you modify m_pd.h, then you are modifying upstream sources, which makes it complicated for distribution.
In some cases, the setup() function allocates memory, which needs to be aware of the data type size.
well, just use t_float or t-sample (as appropriate) with the correctly defined PD_FLOAT_PRECISION.
i'm really only talking about how to make sure that PD_FLOAT_PRECISION is defined to the right value.
Adding additional methods seems unnecessary--unless specific performance problems can be avoided.
it's only about guaranteeing consistency between the host (pd) and the client (the external). i don't see so many alternatives, but probably you know some clever trick.
I don't anticipate any problems with running 64-bit Pd on a 32-bit
i'd suggest to use "double precision Pd" (i know it's longer to type) if you refer to 64bit data types, and "64bit Pd" if you refer to address size.
system, in principle, just as long as the correct data types are set for pointers (same size as t_int) and signals (size of t_sample) differently.
that's the problem i'm trying to solve.
fgmasdr IOhannes