Chuckk Hubbard wrote:
On 7/26/06, Martin Peach martin.peach@sympatico.ca wrote:
padawan12 wrote:
I see a free software tool that does what Pd does and outputs code as an inevitability, sooner or later, it's just
the logical
thing to do. It's just that I'm rather scratching my head wondering
why it doesn't
do so already. Perhaps I've forgotten some fundamental reason why
exploding the netlist
into a code listing might not be trivial, reenterancy maybe,
Well possibly the fact that most pd patches are not strictly procedural, a list of instructions that is run through once. Messages can arrive at any time to modify what is going on... PD is already written in C and is basically a scheduler that calls functions at the appropriate times based on the messages the functions are emitting. It seems to me you can't get any further than that in C. Sure you can manually write any particular patch more efficiently as a standalone program but I doubt there is a general way to do that since there is no way to predict every possible state of every possible patch, hence no way to guarantee that a program is really the same as the original patch. IMHO, Martin
Does Pd actually replace the objects in a patch with their machine code?
Yes. A message arriving at an inlet results in a function call to machine code.
It seems like, if the behavior of the program and the behavior of any one object are derived from C code, you could just plug the necessary pieces of C code together in the same relationships as the objects in the patch. I don't think the extra step of then compiling the C code would be much of a PITA for anyone using Pd. If you really wanted a small program, you could even take out parts of objects you don't need, if that doesn't violate anyone's license. As in, if you have no [/~] objects, take that section out of the signal math file. Kind of the way Csound works.
That would take some kind of stripping program that could determine which parts of the ensemble were actually used in a patch and then remove the unused code, putting it back together while adjusting all the function addresses to fit the new space. Some linkers can do this when incorporating libraries into code, so a program that was statically linked against pd.lib could remove the parts of pd.lib that weren't used. Leaving aside the TCL/TK part (i.e. you won't have anything to look at or take user input), it should be feasible in many cases, but as I said, for any given patch, there is no way to guarantee that some code will never be called. (Imagine for example someone sending arbitrary messages to a netreceive object.) To me it looks easier to script pd to operate the patch as is, or remove some functionality from pd (as with kiosk mode) so an untrained user can't wreck the patch. Martin
Maybe it wouldn't be much benefit for existing Pd users, but I bet it would draw new users in. Then again, I realize it wasn't part of the original vision behind Pd; but that needn't stop it.