[PD] polypoly's second inlet

[Phil Stone]

Frank Barknecht wrote:
> 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.
>   

Clever -- that would work for getting the parameters to the desired 
voice and that one only.  I still worry a bit about the inefficiency of 
64 copies (for a 64-voice synth, which is what I've been using) of my 
big parameter list flying around needlessly.

Frank, if you have a few moments, could you explain a little about how 
this wiring works in [polypoly]?  I see in the [pd init] subpatch of 
[polypoly] where the connections are made, but I don't understand why 
the first inlet goes only to the current [poly]-selected voice, while 
the second goes to all second inlets of all the cloned abstractions.   
It's hard to envision what the final patch would look like, or why it 
would look that way, at least.

> > (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.

I understand.

> It may be nice if [poly]
> would support "note amp foo bar etc." lists.
>   

I agree; that would make [polypoly] useful for any conceivable kind of 
abstraction cloning, not just synth voices constrained to a {note, amp} 
model.   But you can only work with what you have, of course.

> Maybe you will be happier with using [ngpoly4] directly?
>   

I have been using [nqpoly4] (specifically, your update of it) quite 
productively, but I am excited by the possibility of unscheduled (i.e., 
live) note-offs, which is what [polypoly] offers.

I know sometimes it's hard to hear "tone" in email, so I just want to 
make it clear that I am not criticizing [polypoly].  I think it's 
awesome, and am very grateful for your work on it.  I'm trying to 
understand it better, though.


Respectfully,

Phil Stone
UC Davis

> Ciao
> -- Frank Barknecht _ ______footils.org_ __goto10.org__