I should add, the next key step is to remove as many classes as possible from the root namespace (i.e. compiled into Pd). For many, it would be trivial to do, just compile them as individual objects in a libdir. I've already done this for x_list.c, x_net.c, and a couple others. Things like x_arithmatic.c will be trickier, but this does not have to happen at once. It can happen incrementally.
.hc
On Sep 26, 2006, at 9:41 AM, Miller Puckette wrote:
Yes indeed. I'm thinking of automatically having new classes shadow old ones, so that anything in Pd could simpy be "externed" over. Not sure of all the long-term ramifications, but I like the idea.
cheers Miller
On Tue, Sep 26, 2006 at 08:30:44AM +0000, carmen wrote:
and that is the question: why do we necessarily need the fftw based fft-objects in plain pd and cannot use externals?
so the only drawback is see is: the objects are called [fftw~] instead of [fft~]; but lo and behold, i vaguely remembered krzysztof magic in cyclone, where a newly loaded class raises itself over an already existing class. while he is using it to overwrite objects from other externals (e.g. iemmatrix's [matrix~]), i don't see any reason why this should not work with internals.
et voila, does this not sound good?
sounds good. maybe there should be some official policy on the overloading of internals?
mfg.adsr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson