This sounds interesting Hans. The question would be, what is the default/empty behaviour of Pd with no internals at all?
Does it just become a framework for connecting objects (the Pd way)?
I ask because I considered the following recently:
Say I have a small collection of objects made in Faust, corresponding to all the common audio rate Pd objects ([phasor~],[cos~], [osc~], [+~] ....) and I want to compare a patch written in vanilla with its implementation using my Faust objects. How could I override the vanilla internals...? (As you can see this eventually leads to the possibility of a Pd which lets me generate source and compile it for standalone apps or whatever.)
a.
On Fri, 9 Nov 2007 16:50:55 -0500 Hans-Christoph Steiner hans@eds.org wrote:
Hey all,
So for the Pd-0.40.3-extended release, I am planning on trying to make the internals available as a library like any other. I'd like this work to be applicable to pd-vanilla, so I'd like to discuss how to make it happen.
I was thinking of just breaking out the classes into their own files, then compiling things as a libdir. This is pretty easy for most of the objects, but I haven't gotten into the DSP classes yet, and I expect things will be more complicated there. And [list] too.
One of the things I am planning on doing for the tkwidget library is making it have a shared libtkwidget.so which each of the object classes uses. Then each objectclass will have its own file, but they still will have shared code. If this works out well, I think it could be a model for Pd libraries in general.
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev