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:
making something sufficiently self-contained
translating a program from one language (.pd) to another (machinecode
or bytecode or even another more efficient high-level language e.g. C++)
- 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