developing Pd-extended against pd-double
The code on https://github.com/pd-projects/pd-double is a double-precision-ready fork of pure-data.git. This means, pd-double is a fork of vanilla Pd, and it can be built in single precision or double precision at will. Apart from the precision option, functionality is the same as vanilla Pd.
There is no double-ready fork or branch of Pd-extended. External libs can be built together with the pd-double core in order to make 'Pd-double-extended'. However, some libs fail to compile, others do compile but may have issues, when built with type double for t_float, t_sample and t_floatarg.
I figured out a development set-up to work on externals within a working copy of pure-data.svn, while they are built against pd-double in a local git repo. Hopefully, this will help maintainers and other people interested with the double-precision-fixing of Pd-extended.
installing the sources
Create a local pd-double clone (fetch-only):
git clone git://github.com/pd-projects/pd-double.git
Create a working copy of pure-data.svn for the purpose. You'll need to hack this copy, so don't use your regular working copy if you have one.
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk pd-svn
For ease of presentation, ~/pd-double/ and ~/pd-svn/ represent local git and svn copies in the following. Replace with your real paths.
In your pd-double, build the double-ready pd core like so:
cd ~/pd-double/ ./autogen.sh && ./configure && make
Do not install. We want to keep the executables in ~/pd-double/src/, and later build the externals in ~/pd-double/extra/. In order to make it look and work like a local install, create a symlink called 'bin/' in ~/pd-double/, pointing to ~/pd-double/src/:
ln -s src bin
You should now be able to run pd-double from within this virtual bin/ dir:
Note that you will not be able to load Pd's regular extra's, like bonk~, fiddle~ etc. They are considered external libs in this development setup, and not installed by default. All core objects are available. The Pd window will say 'PD_FLOAT_PRECISION = 64 bits' at start up. Double precision is set as the default, during the testing phase of pd-double. Probably, the default precision will later change to single, in order to match with Pd as we know it.
building external libs
In your pd-svn, delete pd/ and replace with a symlink pointing to pd-double:
cd ~/pd-svn/ rm -rf pd/ ln -s ~/pd-double/ pd
Now you can selectively build external libs against pd-double, into ~/pd-double/extra/. As an example, this is how to build zexy:
cd ~/pd-svn/externals/ make DESTDIR=~/pd-svn/pd/ zexy_clean creb zexy_install
Remember how ~/pd-svn/pd/ was created as a symlink pointing to ~/pd-double/. Via this symlink, zexy includes the pd-double sources for compilation, and is installed as ~/pd-double/extra/zexy/. Some libs are linked to ~/pd-double/src/pd by ld via the same route. Of course, pd can also be started from within ~/pd-svn/bin/, and in the help browser you'll find libs built this way.
loading externals, using namespaces
Since the code in pd-double is like vanilla Pd, no external libs are loaded by default. The best way to load external objects is by instantiating them with namespaces, like zexy/wrap. If you use the preferences for this purpose, there is a risk that libs from another Pd install will be loaded. Until recently, when Pd could only be single precision, such unintentional loading could go unnoticed very well. But single precision externals are not compatible with a double precision Pd, and vice versa. In the best case, objects produce nonsense output, in the worst case Pd will crash. If you make test patches, please use namespaces for external objects.
svn update and commit
It is possible to update parts of ~/pd-svn/, but not the whole of it. Be careful to skip ~/pd-svn/pd/, which is now a symlink to ~/pd-double/. It should be possible to commit changes in individual external libs or files if you have commit access for pure-data.svn. Also consider submitting a patch to the patch tracker instead. After all, making Pd-extended double-ready goes beyond regular bug-fixing, even though functionality is supposed to remain the same.