[PD] Pd compiling

Mathieu Bouchard matju at artengine.ca
Mon Jan 30 08:00:08 CET 2006


On Fri, 27 Jan 2006, Hans-Christoph Steiner wrote:

> Pd-extended is self-contained.  That's a big motivation in the creation
> of it.

btw, on win32 it's missing PYTHON24.DLL

> But compiling Pd patches isn't purely a question of proprietary vs free.  
> If Pd could be compiled, it could run on embedded systems like mobile
> phones and microcontrollers.  It would be quite difficult to make a Pd
> port to Microchip PIC.

Yeah, there's compiling, compiling, and then there's compiling too. I see 
three things here conflated into one:

1. making something sufficiently self-contained

2. translating a program from one language (.pd) to another (machinecode 
or bytecode or even another more efficient high-level language e.g. C++)

3. cutting on the fat (space): removing unneeded libraries, classes,
   functions, variables, etc.

> Its also a question of flexibility, it would be a nice feature to have.  
> But its probably not easy to implement.

(1) is mostly done by pd-extended

(2) is very difficult. If I were whoever, I wouldn't attempt it without a
completely working PureUnity (tm) test suite. Then I would add functions 
to Pd's API so that the classes may participate in the compilation by 
giving hints to the compiler because else there won't be that much to 
optimize.

(3) would be partially doable now, in the form of providing the user with
a generator for custom pd-extended distributions, which would contain only
the necessary files. Breaking down libraries into single classes helps
eliminate the maximum possible of unused classes just by looking for
unused files. Finer-grained space-saving requires compiler-driven surgery
(Frankenstein on the PIC).

 _ _ __ ___ _____ ________ _____________ _____________________ ...
| 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