I have been using Frank B.'s wonderful abstraction [polypoly] (which is a revision and improvement of [nqpoly]) and getting great results with it. In fact, I'll publish a synth based on it very soon now -- just as soon as I work out this final issue.
I added an extra inlet to [polypoly] in order to be able to send a "clear" message to the [poly] object within it, which manages all the dynamically-created voices. I did this because imperfect input can sometimes drop a note-off and leave a note hanging, and it never gets de-allocated or released by [poly] -- that's what the "clear" message accomplishes.
This actually worked great, with one small problem -- the $0-poly subpatch, which is where the magic of [polypoly] mostly seems to occur, doesn't respond well to editing of its parent. There's dynamic instantiation using $0- variables going on here, and I think that's what is getting messed up by editing -- these extra lines appear in the edited version:
#X obj 50 60 r 1002-in1; #X obj 199 60 r 1002-in2; #X obj 50 200 throw~ 1002-out0; #X obj 199 200 throw~ 1002-out1;
and the subpatch invocation is this:
#N canvas 7 455 362 318 1002-poly 0; (edited)
instead of:
#N canvas 7 455 362 318 $0-poly 0; (original)
These cause startup errors, although after that, everything seems to work fine.
I'm not sure how to correctly edit self-modifying patches such as this.
What's the trick? Should I just edit the text directly? I've attached
the modified version of [polypoly]. By the way, Frank, will [polypoly]
be made available from CVS? I think it's the best thing since sliced bread.
Phil Stone UC Davis
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
This actually worked great, with one small problem -- the $0-poly subpatch, which is where the magic of [polypoly] mostly seems to occur, doesn't respond well to editing of its parent. There's dynamic instantiation using $0- variables going on here, and I think that's what is getting messed up by editing -- these extra lines appear in the edited version:
#X obj 50 60 r 1002-in1; #X obj 199 60 r 1002-in2; #X obj 50 200 throw~ 1002-out0; #X obj 199 200 throw~ 1002-out1;
and the subpatch invocation is this:
#N canvas 7 455 362 318 1002-poly 0; (edited)
instead of:
#N canvas 7 455 362 318 $0-poly 0; (original)
These cause startup errors, although after that, everything seems to work fine.
I'm not sure how to correctly edit self-modifying patches such as this.
What's the trick?
The trick is to start with an empty [pd $0-poly] subpatch and add everything there by dynamic patching only!
That's what the "clear" message somewhere in the initialization subpatch does. So in the end it doesn't matter what's saved inside of [pd $0-poly] after editing, it will be deleted again aynways on startup.
Clearing the subpatch this way ensures, that I keep total control over the subpatch's content and especially over the order, the objects inside of it are created. Knowing the order is important as soon as "connect" messages are used, because these work with enumerated objects.
On dynamic creation of $0-objects, Pd will replace the $0 with its current value, for example "1002", but as that is unique for that patch, it's not necessary to keep an explicit "$0" in the name. As mentioned above: This will be deleted anyways.
Should I just edit the text directly? I've attached the modified version of [polypoly]. By the way, Frank, will [polypoly] be made available from CVS? I think it's the best thing since sliced bread.
Added to @ACTION. ;)
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
By the way, Frank, will [polypoly] be made available from CVS? I think it's the best thing since sliced bread.
Added to @ACTION. ;)
Now checked in to CVSROOT/abstractions/footils/foo/
You'd need these four files from there:
$ ls *poly* polypoly-help.pd polypoly-wrap.pd polypoly.pd voice-poly.pd
The help-file now also mentions the "clear" and "stop" messages.
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
The trick is to start with an empty [pd $0-poly] subpatch and add everything there by dynamic patching only! That's what the "clear" message somewhere in the initialization subpatch does. So in the end it doesn't matter what's saved inside of [pd $0-poly] after editing, it will be deleted again aynways on startup.
With the small caveat that if you don't start with a clean [pd $0-poly], you get errors like:
error: throw~ 1002-out0: no matching catch error: throw~ 1002-out1: no matching catch
on startup. Because of the initial "clear" message you've implemented, this causes no trouble after startup.
From another follow-up:
Forgot to reply to this part: You actually don't need a separate inlet for this. Just send a "clear" or "stop" message to the first inlet! ;)
It's connected to the [poly]-object direct so it will accept all messages, that [poly] accepts as well.
D'oh! Sometimes the obvious approach flies right over my head!
Nevertheless, I appreciate your patience in explaining this powerful
object, Frank, and thanks for putting it in CVS.
Phil Stone http://www.pkstonemusic.com
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
I added an extra inlet to [polypoly] in order to be able to send a "clear" message to the [poly] object within it, which manages all the dynamically-created voices. I did this because imperfect input can sometimes drop a note-off and leave a note hanging, and it never gets de-allocated or released by [poly] -- that's what the "clear" message accomplishes.
Forgot to reply to this part: You actually don't need a separate inlet for this. Just send a "clear" or "stop" message to the first inlet! ;)
It's connected to the [poly]-object direct so it will accept all messages, that [poly] accepts as well.
Frank Barknecht _ ______footils.org_ __goto10.org__