[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