hi Thomas,
well, going dynamic is quite another story, but perhaps this might be of some value to you anyway --
My impression is that the poly~ in msp maintains a separate dsp chain.
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, btw).
There is some overhead price to pay for such a scheme, of course, but apparently not as big as in the original poly~, which is horribly inefficient.
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 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. 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.
Krzysztof
Thomas Grill wrote:
Thomas, are you going to make a polyphonic instrument with real dynamic voice (aka instance) allocation ala Csound, a super-poly~ we all dream of?
Yes, i'll try to as soon as for the next performance all scores have been