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