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 written, all rehearsals have been survived and the concert evening has been extensively celebrated. (maybe there may be a one day delay until i start coding then.....)
T
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
hi,
with pd-0.35 the "click" massege to canvas gives an error about wrong arguments, i could not figure out from the source what has changed. anybody has some idea ?
thx
erich
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
-
Krzysztof Czaja -
rat＠telecoma.net -
Thomas Grill