Hello listers (and Frank B. in particular),
I've been converting a PD synth I've been using from an [nqpoly] voice manager to Frank's new [polypoly]. Mostly, it's working well for me, but one thing about it seems less than optimal, and I wonder if it is intentional.
The first inlet sends its {note, amp} pairs to one and only one instance of the polypoly'd abstraction. The second inlet broadcasts its message to *all* instances (see attached patch for simple illustration).
I can see reasons for wanting it to work that way, so if it was intentional, so be it. It would work much better for my selfish purposes -- I like to send a big list of parameters to the voice that's about to be fired off -- if it only connected to the same instance that the first inlet connects to.
(As an aside, it occurs to me that [polypoly] would be much more
generalizable if the first inlet could send a list *of any size* to the
poly-allocated abstraction, instead of a hardwired {note, amp} pair.
Then I would be happy to see the second inlet be "global", because I
wouldn't need it anymore. I'd just send a big list, including note and
amplitude as well as all my other parameters, to the first inlet. The
drawback is that this would require a custom version of [poly], since
[poly] assumes {note, amp} pairs.)
I get lost in the auto-creates and auto-connects in [polypoly]'s innards, so I can't figure out how to play with this. I'm awfully grateful for this powerful object, though. If I can get it working, my synthesizer patch will work great for process music (which is all nqpoly can really do), *and* live playing. Thanks, Frank.
Phil Stone UC Davis
#N canvas 264 37 332 200 10; #X obj 38 56 pack 60 120; #X obj 63 5 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1 ; #X obj 63 26 t b b; #X obj 38 88 polypoly 12 1 polytestvox; #X obj 123 56 pack 1 2 3 4 5 6 7; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 2 1 4 0; #X connect 4 0 3 1;
#N canvas 314 159 340 257 10; #X obj 59 49 inlet; #X obj 164 49 inlet; #X obj 164 89 print 2ndInlet; #X obj 59 89 print 1stInlet; #X obj 62 161 outlet~; #X obj 142 161 outlet~; #X connect 0 0 3 0; #X connect 1 0 2 0;
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
I've been converting a PD synth I've been using from an [nqpoly] voice manager to Frank's new [polypoly]. Mostly, it's working well for me, but one thing about it seems less than optimal, and I wonder if it is intentional.
The first inlet sends its {note, amp} pairs to one and only one instance of the polypoly'd abstraction. The second inlet broadcasts its message to *all* instances (see attached patch for simple illustration).
I can see reasons for wanting it to work that way, so if it was intentional, so be it. It would work much better for my selfish purposes -- I like to send a big list of parameters to the voice that's about to be fired off -- if it only connected to the same instance that the first inlet connects to.
You could use a little trick by connecting the second inlet to the right inlet of a [list] object inside your wrapper to store, but not activate new settings on a per note level. Then bang the left inlet of this [list] with the "noteon"-message coming in to the left inlet of your wrapper with a [t a b] or something like that.
(As an aside, it occurs to me that [polypoly] would be much more generalizable if the first inlet could send a list *of any size* to the poly-allocated abstraction, instead of a hardwired {note, amp} pair.
Actually this is a limitation of [poly], and [polypoly] really was made to be a handy wrapper around [poly] that mimicks most of its functionality and can alsmost be used as a drop-in replacement without having to refer to the help patch again. It may be nice if [poly] would support "note amp foo bar etc." lists.
Maybe you will be happier with using [ngpoly4] directly?
Frank Barknecht _ ______footils.org_ __goto10.org__