On Thu, 19 Jan 2006, Thomas Grill wrote:
Am 18.01.2006 um 20:56 schrieb Hans-Christoph Steiner:
Thomas posted an idea a while back about making all of the core Pd objects into a library and having Pd itself just be the very core. I am thinking of doing this for the next Pd-extended, and this got me thinking. It would be great to have a SIMD version of the Pd-core lib as well. This would be easier to deploy and maintain since it could be in /externals/ rather than part of Pd.
what i forgot to mention about the separation of core and internals is that it requires a bit more code restructuring than just linking the object files into two separate binaries. I remember some DSP functions to be associated with internals - this code must be moved over to the core part. But this should be done anyhow.
I expect some object classes to not be really separable from the core, and I don't necessarily mean DSP: think of [inlet], [outlet], [pd]...
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.
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