On Mon, Oct 3, 2011 at 10:19 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-03 16:31, Hans-Christoph Steiner wrote:
These all sound like good ideas to try. My only concern is that we might let the deployment issues distract from the issues at hand about getting it actually working first.
i'm definitely with you here. what is still missing in terms of "getting it actually working first"?
afaict, katja's patches do make pd itself double-precision ready (the patches might have to be reviewed as far as coding-style is concerned though)
otoh, i wouldn't start "porting" externals before we have a deployment strategy.
one important thing missing right now, is how to compile Pd in a given precision without having to edit m_pd.h technically i think that the define stuff and the like should go into a separate file "types.h" (probably "m_types.h") which is generated from m_types.h.in during configure time, and which is included by m_pd.h (which should remain non-generated) the question is, what miller would think of such a thing.
Would you prefer to set the types at configure time through a file--or for example by adding a -DDOUBLE compiler flag? The affected locations of code defining the types could just use #ifdef DOUBLE
In either case, the configure option seems necessary. It still seems an open question how best to offer the double-precision types to externals developers.
In some cases, the setup() function allocates memory, which needs to be aware of the data type size. Otherwise, memory for signals is allocated through Pd's DSP graph generation routines, so that only changes to externals is to compile perform routines with the given data type.
Adding additional methods seems unnecessary--unless specific performance problems can be avoided.
In terms of packaging, I can see having 64-bit distros run double-precision Pd for all packages, and 32-bit distros run single precision. That should cover the bulk of situations, the other situations can be covered by custom builds. Having all the 64-bit packages use double-precision Pd is of course going to happen after a while, once we have the bugs worked out. Here I can see an advantage of the monolithic Pd-extended package: its an easy, self-contained test bed.
definitely, the traditional Pd-extended will have an easier time here.
nevertheless, the advent of ~/pd-externals for the user has made things significantly more complicated in terms of "just works".
fgmasdr IOhannes
I don't anticipate any problems with running 64-bit Pd on a 32-bit system, in principle, just as long as the correct data types are set for pointers (same size as t_int) and signals (size of t_sample) differently.