[PD] Pd standalone instruments ...

[Martin Peach]

Chuckk Hubbard wrote:
> On 7/26/06, Martin Peach <martin.peach at 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.
>