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__
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
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.
Hm, I think, you're misreading the automatically generated instances of the wrapper abstractions a bit. You'll probably see it a bit better if you move around the abstractions in [pd $0-poly] a bit, otherwise the patchcords and objects are on top of each other.
Basically [pd init] only sets up the basic stuff in [pd $0-poly], that is, first it clears this subpatch, then it creates "fake inlets and outlets" as senders rsp. receivers.
Then the wrappers are created and connected like this:
[r in1]
|
[polypoly-wrap whatever 0 ...]
|
[polypoly-wrap whatever 1 ...]
|
[polypoly-wrap whatever 2 ...]
|
[polypoly-wrap whatever 3 ...]
|
...
[r in2] then is connected to every second inlet of polypoly-wrap and both signal outlets (second and third outlets) of polypoly-wrap are connected to the fake signal outlets: [throw~ out0] and [throw~ out1]
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.
Btw.: My proposed [list] trick is almost directly taken from Miller's example and explanation in 3.audio.examples/D11.sampler.poly.pd only Miller uses a [pack 0 0 0 0 0 0 0] instead of [list] probably just because the patch was written when Pd didn't have [list]. You could study this patch and the respective part in Miller's book as well to get a feel for the idiom I'm referring to.
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.
I think I understood you quite well and I definitely welcome your kind of constructive feedback and suggestions.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
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.Hm, I think, you're misreading the automatically generated instances of the wrapper abstractions a bit. You'll probably see it a bit better if you move around the abstractions in [pd $0-poly] a bit, otherwise the patchcords and objects are on top of each other.
Ah, sorry, ignore this above. You have a correct understanding of the wiring already. The additional thing is this: Inside of [polywrap] there's a [route $2] which filters out only the messages whose first element matches the voice number. The voice number is automatically generated by [poly]!
Matching messages are sent to the actual custom abstraction. The non-matching messages are sent further along the first outlet to the next [polywrap] where another [route] is waiting for the correct voice number and so it goes on.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Phil Stone