On Thu, 19 Jan 2006, Mathieu Bouchard wrote:
However, I expect 80% or 90% of the internal classes to be externalizable. Let's do it for those classes first. Reuse the work of PDa if it makes sense.
There is probably not that much that you can actually reuse. For a start, I think externalizing the ~ objects makes most sense. These are also the objects that will benefit from SIMD, the message based objects won't run any faster because their performance is bottlenecked by scheduling and other factors that can't take advantage of SIMD.
Instead of the typedef, what I did was to redefine t_sample. Unfortunately the usage of t_sample as the base DSP type is not fully consistent in Pd, which means you have to change several occurences of t_float or float directly to t_sample in the dsp _perform routines.
It would be nice to have them consistent, because we could redefine t_sample to "double" and compile a high-end version of Pd. I admit that I doubt that it would really improve sound quality, but its a good point for selling.
Like, you know, Pd sounds better because it runs with 64 bit numbers.
Guenter
BTW, about PDa, it would make sense to make the Pd source C++-compatible, because if we can include C++ code in Pd, it's possible to introduce a fixed-point type that could be typedef'd as t_float, so that for almost all classes there would be no need to explicitly add integer code. (I haven't looked at PDa so I don't know whether it already does that...)
I had made some C++-related fixes but I think that they were part of the same batch of removal of unused variables and those changes have been reverted.
Maybe this ought to be a topic in the pd-dev meeting.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev