dyn~ - was: Re: [PD] Pd and jack (again)

Thomas Grill t.grill at gmx.net
Tue Jan 28 21:14:07 CET 2003

> The PD/jMax external closest to that latter ideal is, of course, GridFlow.
> But it's not like GridFlow can even get close to that ideal because there
> are way too many classes/externals to rewrite, and it does not handle DSP
> at all, etc.

I thought over it for quite some time and i've come to the conclusion that
using standard pd message and dsp objects is the way to go.

> May you explain how dyn~ would work?

Following is an explanation of how my test-dyn~ works. This might actually
change because it's more a proof-of-concept. It's very simple (and in
principle mostly like rabin~ as i realized afterwards). dyn~ creates a
hidden patcher where objects can be created/destroyed and
connected/disconnected. The number of (signal/message)inlets and outlets is
specified on the command line. There are several messages:

new name object [args] ... creates a pd object (or abstraction) which can in
the following be referenced by "name"
del name .... deletes the object
conn [name1] outlet# [name2] inlet# ... connects two objects (signal or
message)... if name1 or name2 is omitted it refers to the dyn~ inlets or
dis [name1] outlet# [name2] inlet#  ... delete the connection
send name inlet# message  ... sends a message to an object
reset ... clears all
reload ... reloads objects and abstractions (and retains the connections)

This is the dyn~ pd object which is just steered by messages... of course
it's a goal to implement an similar interface into pyext... than one will be
able to create signal graphs in an object-oriented manner.

any drawbacks that i'm unaware?


More information about the Pd-list mailing list