So far I found code in cyclone (sic.c) and in "fofsynth~" in ggee (under "experimental"). Both of these seem to check whether cos_table is nonzero. So I suggest that I simply not export cos_table and remove both cos_table and COSTABSIZE from m_pd.h. Attempts to compile them for newer architectures will then fail but they both seem to contain their own table-making code and can be fixed simply by removing the reference to an external cos_table.
I'm mostly concerned with keeping binary compatibliity, not source compatibliity, with old externs - and this probably only matters on old architectures (powerpc, intel 32-bit). For those I can keep generating cos_table but not make it available to m_pd.h, and for newer architectures (including anything ARM I think) I can simply not supply cos_table at all.
I really don't know why I ever thought it a good idea to export these :)
M
On 5/26/24 6:19 PM, Alexandre Torres Porres wrote:
Em dom., 26 de mai. de 2024 às 11:02, Christof Ressi info@christofressi.com escreveu:
Are there any existing externals that do use cos_table? When in doubt, we could keep the old cos_table around, but deprecate it. In the future we can remove the cos_table symbol, so old externals simply won't load.
Cyclone used to have it, but we removed long ago when updating [cycle~]. Old versions still have it of course and 'nilwind' (which is basically an old version of Cyclone) still has it https://github.com/electrickery/pd-nilwind/blob/cf4f468f5585608c997c501cf305... https://urldefense.com/v3/__https://github.com/electrickery/pd-nilwind/blob/cf4f468f5585608c997c501cf3057d45fc2402b9/shared/sickle/sic.c*L69__;Iw!!Mih3wA!EUv21nqXrabdxVCU3iqtXuD70WmtWgewbGfUNbhPX3yx0dyANcb10KOrHUEG7_qvY9VQ0CFttQ$ but can be updated if the idea is to maintain an old version of cylone...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...