[PD-dev] externals implementing PD_FLOAT_PRECISION can't be compiled against pure-data, libpd, pd-l2ork etc

katja katjavetter at gmail.com
Sat Nov 12 15:56:09 CET 2011


To answer my own mail, let's just do this whenever using PD_FLOAT_PRECISION:

#ifndef PD_FLOAT_PRECISION
#define PD_FLOAT_PRECISION 32
#endif

to make sure code remains compilable against all sorts of Pd. When
PD_FLOAT_PRECISION is not defined, it is safe to assume t_float etc
are float.

Katja



On Sat, Nov 12, 2011 at 3:30 PM, katja <katjavetter at gmail.com> wrote:
> We now have PD_FLOAT_PRECISION in the Pd-extended API (even though
> it's value is still fixed at 32) and in Pd-double. This macro is
> sometimes needed for conditional compilation when making external libs
> ready for double precision. For example, to call sf_read_float() or
> sf_read_double() in libsndfile, or in case of a type punning trick
> which must be defined according to data type.
>
> Libs which use PD_FLOAT_PRECISION for such reason, are no longer
> compilable against pure-data, libpd, pd-l2ork and other types of pd.
> This is now the case for creb and smlib, for which I committed
> double-ready changes this week.
>
> Before I proceed committing to other libs, this issue should discussed
> with authors and maintainers of pure-data, it's forks, and external
> libraries. Historically, external libs have always been compilable
> against Pd flavours other than Pd-extended, no? It would be an awkward
> experience for anyone unsuspectingly copying a lib's latest revision
> from pure-data.svn and find it's no longer compatible with Pd other
> than Pd-extended and Pd-double! Technically, the solution is simple: a
> line '#define PD_FLOAT_PRECISION 32' in the API's would restore
> compatibility, when t_float etc. are still typedef'ed as float. It is
> not so elegant we have to bother many people with our double precision
> efforts, but it's impossible to develop this in isolation.
>
> Katja
>



More information about the Pd-dev mailing list