On Thu, 2011-10-13 at 01:28 +0200, katja wrote:
Today I built the sources from the pd-double autobuild on OSX 10.5. In order to force double precision I added --enable-double-precision to the PD_CONFIGURE_FLAGS in the Makefile for darwin_app. This gives a double precision core, but unfortunately the externals are still single precision.
Impatiently, I've set PD_FLOAT_PRECISION in m_pd.h to 64 here. Two weeks after the announcement of double precision Pd-extended, I'm eager to finally know what it looks like.
Sounds like a good dev setup. The stuff I committed is more about trying to automatically set things up for people building themselves. It definitely an open question how to handle this. Like your situation, what's the easiest way to force double on 10.5 or other 32-bit platform? Another way would be to add -DPD_FLOAT_PRECISION=64 to the CFLAGS in packages/darwin_app/Makefile.
Well? It refuses to build. Or more precisely: some functions in some files in some libs can't be compiled, mostly because of 'incompatible pointer type'. Nothing so serious, but these libs have to be omitted for the moment until they're repaired, otherwise pd-double-extended can not even be built for testing. The culprits are:
creb cw_binaural extra smlib vbap
If you want SVN commit access, check the puredata.info dev wiki for the instructions.
About bsaylor and unauthorized I don't know because there were unsatisfied dependencies for them on my system. I can repair 'extra' tomorrow and commit to pd-double.git.
One thing: there is the stuff in pd/extra, then there is a copy of that stuff with an alternate build system in externals/extra. They should be in sync code-wise. But just be sure to only commit to pd/extra in the pd-double.git, not externals/extra in the pure-data SVN.
By the way you can use the help file for [cyclone/mean] to check whether the cyclone lib (and probably the whole of pd-extended) is built with the same precision as the core, because this class is 'by it's nature' double-precision-ready. If it gives garbage output, the build is wrong, not the C code. Hopefully there's many more double-precision-ready classes in the external libs, that's what we'll find out shortly.
I think most should be ready to go, as long as they used t_float and t_sample well. Mostly, if they used t_float for both t_float and t_sample, which is pretty common, my guess is that will work too.
.hc