dyn~ - was: [PD] PD signal graph

[Thomas Grill]

Hi Krzysztof,
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
scripting).

> My impression is that the poly~ in msp maintains a separate dsp
> chain.

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
outlets.

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
respect)

best greetings,
Thomas