[PD] PdContainer in Pd devel (was: OSC in pd canonical)

Mathieu Bouchard matju at artengine.ca
Mon Nov 28 03:59:19 CET 2005

On Wed, 23 Nov 2005, Thomas Grill wrote:

> > Quick survey: how open are developers to the following ?
> > (a) inclusion of C++ code in Pd devel branch
> > (b) inclusion of C++ STL code in Pd devel branch
> in principle i'm positive to both, because every c compiler i know of is
> able to compile c++.

One major problem is that there tends to be greater variation
(incompatibilities and bugs) between C++ compilers than between C 
compilers. Another problem would be the ABI incompatibilities, but as long 
as our public *.h files don't contain any C++-specific things, this is a 

> On the other hand, i'm not in favor of inclusion of externals into PD.

What did Miller just do? Oh right, he didn't include [list] from outside,
he wrote it from scratch. But still, prior to 0.39, that was something
that was handled mostly by externals such as the ones in cyclone, maxlib,
zexy, gridflow and whatever. How did we go from "list processing is an
external feature" to "list processing is an internal feature" ? Certainly
not by not being in favour of inclusion of externals into PD.

> I personally would even throw out so-called internals and all graphical
> objects of course, with a compact kernel remaining.

Well, I would mostly agree, as long as those things remain bundled with
the core pd, at least in the way that [expr~] [bonk~] [fiddle~] currently
are. Besides, that's how it was in jMax.

Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
Freelance Digital Arts Engineer, Montréal QC Canada

More information about the Pd-list mailing list