dyn~ - was: [PD] PD signal graph
t.grill at gmx.net
Mon Jan 27 12:36:51 CET 2003
i had a longer look at your rabin~ code and i found that it uses the same
approach that i had in mind.
However, my intention was not to have something identical to Max-poly~ but a
means to dynamically create complicated patches (for example with Python
> My impression is that the poly~ in msp maintains a separate dsp
This is true and i'll not implement it at this time. I want to stay
compatible with pd version changes.
> In rabin~, I have taken a shortcut of fake-loading instances as if
> they were regular abstractions -- and thus used the main dsp
> chain. The trick was to implicitly replace all inlet(~)s and
> outlet(~)s with in(~)s and out(~)s, which were 'remotely'
> connected to the main rabin~ object (hence the 'r' in the name,
I use proxy input and output objects which are connected to the objects
dynamically created inside the external.
> The poly~ in msp does not support editing of an embedded
> abstraction. I have enabled this in rabin~. No idea, though, how
> this could be done if having a separate dsp chain.
I won't support editing as it would disturb the object database of my
external. However, there's a possibility to view a patch.
> I have not decided yet if maintaining a separate dsp chain is the
> way to go for cyclone's poly~. Maybe your project will serve as
> a clue.
I'm sorry... i guess not....
For the time being, the main stopping factor is Pd's
> inability to create 'mixins', i.e. inlets (other than first)
> accepting both signal and control connections.
That's not a real problem for me... i can get along with separate inlets and
I'll publish a first version of dyn~ as soon as i have the time to do it....
(there's one drawback with it... my external needs a tiny patch to pd
exposing the "newest" pointer... i already patched cvs devel_0_36 in this
More information about the Pd-list