Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I just wrote a quick test of what happens when you play hundreds of
oscillators. Thanks to nqpoly4, its quite easy.
nqpoly4 is great fun, warts and all. I look forward to playing with this when I get home, hc.
Okay, this inspired me to finally do something I wanted to do for a loooong time: I think, nqpoly4 is a very useful patch, however I always found it hard to see what's going on, I didn't like the use of the non-deprecated namecanvas, where a subpatch would be enough, and most of all I found the editing restrictions awkward to say the least.
Attached is a reworked version of nqpoly4, which should be compatible but I only tested it with your many-osc.pd so far.
Changes besides cleanup include an additional inlet that lets you change the degree of polyphony on the fly. Further editing of nqpoly4 does not need to follow the old instructions about counting object indices and creating connections in a certain order etc. You can edit the patch without such hassles now just like any other Pd patch.
Excellent!
A final change I didn't do yet is to change the name to something other than "nqpoly4", which I find a bit hard to type and to memorize. Suggestions welcome.
How about "pgpoly" for "pretty good polyphony"?
I dream of a polyphony object with the dynamic-subpatch-creating advantages of nqpoly4, combined with the capacity to match up note-offs with previous note-ons, which is necessary for live (i.e., indeterminate duration) polyphonic music. Such a beast could be called "vgpoly", for "very good polyphony". :-) This more robust nqpoly4 object you've made makes improvement and extension a little easier to contemplate -- thanks, Frank. Once I have a little more PD experience under my belt, maybe I'll give "vgpoly" a try.
Phil Stone
On Jul 11, 2006, at 7:23 PM, Phil Stone wrote:
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph
Steiner wrote:I just wrote a quick test of what happens when you play
hundreds of > oscillators. Thanks to nqpoly4, its quite easy.
nqpoly4 is great fun, warts and all. I look forward to playing
with this when I get home, hc.Okay, this inspired me to finally do something I wanted to do for a loooong time: I think, nqpoly4 is a very useful patch, however I always found it hard to see what's going on, I didn't like the use of the non-deprecated namecanvas, where a subpatch would be enough, and most of all I found the editing restrictions awkward to say the
least. Attached is a reworked version of nqpoly4, which should be compatible but I only tested it with your many-osc.pd so far. Changes besides cleanup include an additional inlet that lets you change the degree of polyphony on the fly. Further editing of nqpoly4 does not need to follow the old instructions about counting object indices and creating connections in a certain order etc. You can edit the patch without such hassles now just like any other Pd patch.Excellent!
A final change I didn't do yet is to change the name to something other than "nqpoly4", which I find a bit hard to type and to
memorize. Suggestions welcome.How about "pgpoly" for "pretty good polyphony"?
I dream of a polyphony object with the dynamic-subpatch-creating
advantages of nqpoly4, combined with the capacity to match up note- offs with previous note-ons, which is necessary for live (i.e.,
indeterminate duration) polyphonic music. Such a beast could be
called "vgpoly", for "very good polyphony". :-) This more robust
nqpoly4 object you've made makes improvement and extension a little
easier to contemplate -- thanks, Frank. Once I have a little more
PD experience under my belt, maybe I'll give "vgpoly" a try.
nqpoly4 is great for anything that needs multiple instances of the
same object, not just polyphony. You can ignore the voice management
feature and just use it as a way to allocate and address many
instances easily. For example, if you use the instance number to
generate a [receive] or [namecanvas] name you can address the
instances easily. Or you can to it in the message format, have each
instance only respond to messages that start with its instance number.
Its great that its been improved, its such a handy object. The funny
thing is that pix abandoned it saying that it could not be improved
without breaking backwards compatibility. The thing that I am
planning on adding is making it behave like a regular object so that
you don't need to copy it to the same dir as your own objects. I
think it shouldn't be so hard to do with [getdir]. That seems to be
the biggest problem with nqpoly4 for me.
.hc
¡El pueblo unido jamás será vencido!
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Its great that its been improved, its such a handy object. The funny
thing is that pix abandoned it saying that it could not be improved
without breaking backwards compatibility. The thing that I am
planning on adding is making it behave like a regular object so that
you don't need to copy it to the same dir as your own objects. I
think it shouldn't be so hard to do with [getdir]. That seems to be
the biggest problem with nqpoly4 for me.
Doesn't it work for every abstraction that is in your path for you? In my tests, it did. I think it is a resonable restriction to let nqpoly4 only create objects that are known to Pd this way.
Another interesting change might be to make it work together with [poly]'s way of voice allocation. Or maybe that's already possible? I didn't check it out so far.
And are 4 arguments enough? It would be trivial to add more, in case this is needed.
Then the second inlet of nqwrap4.pd actually isn't needed, one could send a loadbang-message to the "pd-$0-poly"-receiver instead, but I kept the inlet for backwards compatibility.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Hans-Christoph Steiner -
Phil Stone