double precision?
Pd can be compiled for double precision, are you able to compile plugdata like that too? it'd need 64 bits externals and if you can help me we can have double precision ELSE and Cyclone ;) tell me what I have to do and I'll do it.
Nice, I think the only thing I need to do is set the PD_FLOATSIZE macro to 64 by compiling with "-DPD_FLOATSIZE=64", and that should do it. I compile libpd, ELSE and cyclone into a single library, so to get this in PlugData I can just set this flag myself and it should work. After that it's important that you use t_float (which is a double now) for all audio variables instead of float.
I think it would be nice to use 64-bit precision in the plugin version, and 32-bit in the standalone for compatibility with externals. The plugin can't load externals anyways, might as well improve the audio quality then.
After that it's important that you use t_float (which is a double now) for all audio variables instead of float.
give me examples
I've looked at it and it looks mostly corrrect to me so far, but it's hard for me to guess which floats are used for audio and which aren't. I'm now using PD_FLOATSIZE=64 and having no problems at all. I assume that's because the worst thing that could happen is that an object just converts it back to a float at some point, which is not great but also doesn't break anything.
Some of the objects that need to be looked at are the random generators.
randf = ((float)((val & 0x7fffffff) - 0x40000000)) * (float)(1.0 / 0x40000000) (rand.f~.c, line 53)
I don't know much about random generators so I might be wrong, but that looks like it won't work for doubles. I think it'll generate a floating point random number, and then assign that to double value, meaning only a part of the double's bits will be randomised. It's not even that bad, is just doesn't utilise the increased range.
Thinking of this, I should enable the compiler warning for silent float-double conversions to see all the potential problems.
This sounds good. Possibly have a setting for standalone to use double precision, set to standard as default.
It can't be a setting, it needs to be decided at compile time :(
put this in the list before 1.0 :) in the end you may just offer 64 bits, which makes more sense
There are a few things to consider. Making plugdata use 64-bit float would break compatibility with 32-bit float externals, so for the standalone I probably won't do it. I could offer a separate 64bit float version maybe?
Then for the plugin version, if we can't load externals anyway, we might as well make it use 64-bit floats.
I'm still planning propose some small changes to pd-vanilla to make sure externals can run in multi-instance pd if the externals are recompiled with the PDINSTANCE/PDTHREAD flags, and if you have to recompile it anyway, might as well also make it 64-bit float. The plan is to create a set of "verified" plugdata externals, that are recompiled from scratch and are compatible with both DAW and Standalone plugdata. This way, we can have the most popular externals packages available in plugdata, without having a super bloated binary and build system. Ofelia, Gem, zexy and flucoma would be some good candidates.
I think I have all of zexy covered in ELSE, it is something similar to else actually... if something is missing, I can add, or maybe it is the case where many patches use it coz it's an important/famous/widely adopted legacy library