Add 64-bit perform routines and dsp_add functions to objects that don’t already have them.
Code in all externals needs to be reviewed for assumptions made about the size of longs and floats in atoms. I did some of this work some time ago and replaced many instances of atom->a_w.w_long with atom_getlong() or atom_setlong(), but this should be review carefully given the internal changes to the atom that took place with the recent 64-bit support. In particular, our FullPacket messages that pass a pointer around as a long integer. The main issue is that long is 32 bits under 64bit Windows, and 64 bits under 64bit Mac and *nix.
Any new graphics stuff in the Max 7 API should be incorporated into the (few) graphical objects we have.
Windows-specific issues:
Compile and package Windows 64-bit externals. This is slightly more difficult than it sounds, only because the build system has to be extended to produce a second set of externals with different file extensions (Windows doesn’t support a fat file format the way OS X does).
License issues:
Objects that use libraries licensed under the GPL need to be reconfigured to use other libraries with similar functionality.
\ GSL:
* randdist: boost?
* bdist: boost?
* bessel: math.h provides bessel functions, but they may not be available on Windows depending on the toolchain
\ FFTW:
* analyzer~ and derivative externs like pitch~: FFTS (Fastest Fourier Transform in the South) or Kiss FFT both look good. The former is supposed to beat out just about everything, but the latter may be easier to integrate into our code base.
equilet
commented
9 years ago
Windows-specific issues:
License issues: