I just wrote a quick test of what happens when you play hundreds of
oscillators. Thanks to nqpoly4, its quite easy. Basically, I wrote
a simple patch that detunes the oscillator based on instance number.
So you get hundreds of oscillators slightly detuned around a center
frequency. The PowerMac G5 2.3GHz that I am on right now could
handle 900 instances cleanly.
Just put these files in one folder and double click many-osc-test.pd
to run.
.hc
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.
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.
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.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jul 11, 2006, at 6:17 PM, 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.
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.
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.
Very nice! If its truly backwards, you should check in your update to
the CVS.
abstractions/nqpoly/nqpoly4
A better name would be good, perhaps something related to managing
instances. Perhaps [instances].
.hc
¡El pueblo unido jamás será vencido!
On Wed, 12 Jul 2006, james tittle wrote:
...oh no: more naming to be done ;-) On Jul 12, 2006, at 12:01 AM, Hans-Christoph Steiner wrote:
A better name would be good, perhaps something related to managing instances. Perhaps [instances].
...i like that, or [instancer]?
[instantiator] is more like a word, i mean at least outside of Kentucky, though it's not in /usr/share/dict/* here...
Else, [attack_of_the_clones] would be a much american name, and one could imagine three sequels appropriately named:
[decay_of_the_clones] [sustain_of_the_clones] [release_of_the_clones]
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jul 12, 2006, at 5:48 AM, Mathieu Bouchard wrote:
On Wed, 12 Jul 2006, james tittle wrote:
...oh no: more naming to be done ;-) On Jul 12, 2006, at 12:01 AM, Hans-Christoph Steiner wrote:
A better name would be good, perhaps something related to
managing instances. Perhaps [instances]....i like that, or [instancer]?
[instantiator] is more like a word, i mean at least outside of
Kentucky, though it's not in /usr/share/dict/* here...Else, [attack_of_the_clones] would be a much american name, and one
could imagine three sequels appropriately named:[decay_of_the_clones] [sustain_of_the_clones] [release_of_the_clones]
Damn, you are grouchy these days, how about toning it down a bit?
.hc
On Thu, 13 Jul 2006, Hans-Christoph Steiner wrote:
On Jul 12, 2006, at 5:48 AM, Mathieu Bouchard wrote:
On Wed, 12 Jul 2006, james tittle wrote: [decay_of_the_clones] [sustain_of_the_clones] [release_of_the_clones]
Damn, you are grouchy these days, how about toning it down a bit?
Sorry, I'm more groucho than grouchy, that one email was just a joke. (Some other emails may or may not be.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 14 Jul 2006, Mathieu Bouchard wrote:
On Thu, 13 Jul 2006, Hans-Christoph Steiner wrote:
On Jul 12, 2006, at 5:48 AM, Mathieu Bouchard wrote:
On Wed, 12 Jul 2006, james tittle wrote: [decay_of_the_clones] [sustain_of_the_clones] [release_of_the_clones]
Damn, you are grouchy these days, how about toning it down a bit?
Sorry, I'm more groucho than grouchy, that one email was just a joke. (Some other emails may or may not be.)
Oh, and let me give out references for my jokes so that even though explaining them make them boring, at least they won't be taken like insults:
http://en.wikipedia.org/wiki/Star_Wars
http://en.wikipedia.org/wiki/Groucho_Marx
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jul 12, 2006, at 5:48 AM, Mathieu Bouchard wrote:
On Wed, 12 Jul 2006, james tittle wrote:
...oh no: more naming to be done ;-) On Jul 12, 2006, at 12:01 AM, Hans-Christoph Steiner wrote:
A better name would be good, perhaps something related to
managing instances. Perhaps [instances]....i like that, or [instancer]?
[instantiator] is more like a word, i mean at least outside of
Kentucky, though it's not in /usr/share/dict/* here...
...um, "more like a word"? I think they're both equivalently made-
up: If I wanted help move-ing, I would call a "mover", not a "move-
inator"...but then, that's one of those crazy things about english:
glop everything together, but try to only use what sounds good (ymmv)...
Else, [attack_of_the_clones] would be a much american name, and one
could imagine three sequels appropriately named:
...why would it be more american? Did we invent cloning? I thought
dolly was scottish...?
:-P
jamie
Hallo, james tittle hat gesagt: // james tittle wrote:
On Jul 12, 2006, at 5:48 AM, Mathieu Bouchard wrote:
On Wed, 12 Jul 2006, james tittle wrote:
...oh no: more naming to be done ;-) On Jul 12, 2006, at 12:01 AM, Hans-Christoph Steiner wrote:
A better name would be good, perhaps something related to
managing instances. Perhaps [instances]....i like that, or [instancer]?
[instantiator] is more like a word, i mean at least outside of
Kentucky, though it's not in /usr/share/dict/* here......um, "more like a word"? I think they're both equivalently made- up: If I wanted help move-ing, I would call a "mover", not a "move- inator"...but then, that's one of those crazy things about english:
glop everything together, but try to only use what sounds good (ymmv)...
I think, [instapoly] sounds best.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On 7/14/06, Frank Barknecht fbar@footils.org wrote:
I think, [instapoly] sounds best.
Okay, but Acid Pauli is _really_ cool! Thanks for the tip.
cheers dafydd
On Fri, 14 Jul 2006, james tittle wrote:
...i like that, or [instancer]?
[instantiator] is more like a word, i mean at least outside of Kentucky, though it's not in /usr/share/dict/* here...
...um, "more like a word"? I think they're both equivalently made-up: If I wanted help move-ing, I would call a "mover", not a "move-inator"...
But what do you want help for in this case? instancing or instanciating?
"verbing weirds language" -- Calvin
Else, [attack_of_the_clones] would be a much american name, and one could imagine three sequels appropriately named:
...why would it be more american? Did we invent cloning? I thought dolly was scottish...?
I'm sorry for the George Lucas reference. I didn't actually see the movie of that name. Worse, I assume that everyone else has at least heard the name of the movie. BTW, it's an american movie.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Very nice! If its truly backwards, you should check in your update to
the CVS.abstractions/nqpoly/nqpoly4
I now tested the example patches as well and they worked fine so I checked this new version into CVS. Compared to the version posted here I also added a third inlet to set the name of the object to create through a message.
Please test.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, Jul 12, 2006 at 12:17:06AM +0200, Frank Barknecht wrote:
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.
fbpoly? This is realy great work!
Chris.
chris@mccormick.cx http://mccormick.cx
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
On Wed, Jul 12, 2006 at 12:17:06AM +0200, Frank Barknecht wrote:
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.
fbpoly? This is realy great work!
Funny, that's how I named the directory containing my copy of nqpoly4. But actually I'm leaning towards another name currently: "acidpoly" which is a nod to an alias of a cool german musician: "Acid Pauli" ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi Frank and the list,
I was searching for some help with nqpoly4 and found this from last July...
Frank Barknecht wrote:
Attached is a reworked version of nqpoly4, which should be compatible but I only tested it with your many-osc.pd so far.
I still can't understand how to create abstractions for nqpoly and get it to call them, but at least your version looks a bit cleaner ;-)
Can you explain in simple steps how to use this patch?
Also, if I wanted dynamic voice handling (i.e. voices shut off when not in use to save CPU), does nqpoly handle this by itself or would I need to build a [switch~] into the abstraction?
thx, d.
On Dec 8, 2006, at 1:28 PM, derek holzer wrote:
Hi Frank and the list,
I was searching for some help with nqpoly4 and found this from last
July...Frank Barknecht wrote:
Attached is a reworked version of nqpoly4, which should be compatible but I only tested it with your many-osc.pd so far.
I still can't understand how to create abstractions for nqpoly and
get it to call them, but at least your version looks a bit cleaner ;-)Can you explain in simple steps how to use this patch?
The right inlet serves as the loadbang. You need to use the right
inlet instead of regular [loadbang]s The left inlet is where the
messages come from. Your patch needs to take its command from the
left inlet, then when it has finished executing that command, it
needs to send a bang to the outlet to tell nqpoly4 that its available
again for another command. That's about it.
Also, if I wanted dynamic voice handling (i.e. voices shut off when
not in use to save CPU), does nqpoly handle this by itself or would
I need to build a [switch~] into the abstraction?
Hmm, you'd have to add the [switch~] AFAIK. But it would be really
nice if it handled that for you. That should be possible by having a
[switch~] in nqpwrap.pd and make it controlled by the allocation
logic. That would be very slick and not too difficult.
.hc
thx, d. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 49: "Display your talent"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Hmm, you'd have to add the [switch~] AFAIK. But it would be really
nice if it handled that for you. That should be possible by having a
[switch~] in nqpwrap.pd and make it controlled by the allocation
logic. That would be very slick and not too difficult.
I would prefer to have my own control over switching, so I would not like this to be included in nqpoly4 directly. This is especially important if one is not using any of the inlets of nqpwrap at all like in the additive synth examples I just posted. It's trivial to add switching to the abstraction, which must be written anyway.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Dec 9, 2006, at 8:12 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Hmm, you'd have to add the [switch~] AFAIK. But it would be really nice if it handled that for you. That should be possible by having a [switch~] in nqpwrap.pd and make it controlled by the allocation logic. That would be very slick and not too difficult.
I would prefer to have my own control over switching, so I would not like this to be included in nqpoly4 directly. This is especially important if one is not using any of the inlets of nqpwrap at all like in the additive synth examples I just posted. It's trivial to add switching to the abstraction, which must be written anyway.
Yeah, I was just thinking that same thing, that it would be useful to
have both one with automatic [switch~]ing, and one without. It seems
to me that if you want one to do voice allocation/management stuff,
then that should have built in [switch~] function. But to do
instance creation and management, that would not have the [switch~]
stuff built in.
I wonder if there is a straightforward way to make both, having them
share relevant code...
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yeah, I was just thinking that same thing, that it would be useful to
have both one with automatic [switch~]ing, and one without. It seems
to me that if you want one to do voice allocation/management stuff,
then that should have built in [switch~] function.
I don't think switching can be done in a generic way from the outside without knowing some details of the abstraction to switch on or off.
Take for example midi voice allocation: Basically noteon and noteoff are kind of switch on and switch off messages already. However generally you have a release envelope fading out the sound over a certain time span after the noteoff message arrived. You cannot switch off dsp for a voice unless you know its release length, and this length might only be known inside the voice abstraction.
So for [polypoly] which specializes in midi note allocation the auto-switching feature wouldn't work, you have to built it into your polypoly-abstraction yourself.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I don't think switching can be done in a generic way from the outside without knowing some details of the abstraction to switch on or off.
Take for example midi voice allocation: Basically noteon and noteoff are kind of switch on and switch off messages already. However generally you have a release envelope fading out the sound over a certain time span after the noteoff message arrived. You cannot switch off dsp for a voice unless you know its release length, and this length might only be known inside the voice abstraction.
However another thing to consider came to my mind. Switch~ing abstractions or subpatches on and off has the nasty side effect of being quantized to one block. Attached example illustrates the nastiness of this.
So for tight timing switching on has to be done at least one block *in advance*. For this a [polywhatever] could be interesting that would keep a pool of voices switched on all the time.
Here's an idea for an algorithm to achieve this: [poly] does voice allocation in a regular fashion using a modulo-counter: Assuming voices are counted from 0, then first voice 0 is used, after that voice 1 and so on until voice maxvoices-1, after that it starts at 0 again. Typical modulo.
Now assuming all voices in [polywhatever] are connected to each other, a voice that started to play could send along a message like "switch (myself+1)%maxvoices 1" to switch on the next voice in the circle.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
hi frank
On Mon, 2006-12-11 at 13:10 +0100, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I don't think switching can be done in a generic way from the outside without knowing some details of the abstraction to switch on or off.
Take for example midi voice allocation: Basically noteon and noteoff are kind of switch on and switch off messages already. However generally you have a release envelope fading out the sound over a certain time span after the noteoff message arrived. You cannot switch off dsp for a voice unless you know its release length, and this length might only be known inside the voice abstraction.
However another thing to consider came to my mind. Switch~ing abstractions or subpatches on and off has the nasty side effect of being quantized to one block. Attached example illustrates the nastiness of this.
the attached patch shows that the subpatch is [switch~]ed off too early, but not [switch~]ed on too late.
So for tight timing switching on has to be done at least one block *in advance*.
if i interprete correctly, what your patch is telling me, then one would have to switch *off* one block *later*. it wouldn't be necessary to know in advance, when to switch on, though. it seems like it is enough to add 1.5ms to each [delay] that schedules the switch-off-messages.
For this a [polywhatever] could be interesting that would keep a pool of voices switched on all the time.
Here's an idea for an algorithm to achieve this: [poly] does voice allocation in a regular fashion using a modulo-counter: Assuming voices are counted from 0, then first voice 0 is used, after that voice 1 and so on until voice maxvoices-1, after that it starts at 0 again. Typical modulo.
Now assuming all voices in [polywhatever] are connected to each other, a voice that started to play could send along a message like "switch (myself+1)%maxvoices 1" to switch on the next voice in the circle.
if i am right, that wouldn't be necessary anymore, right?
cheers roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
the attached patch shows that the subpatch is [switch~]ed off too early, but not [switch~]ed on too late.
So for tight timing switching on has to be done at least one block *in advance*.
if i interprete correctly, what your patch is telling me, then one would have to switch *off* one block *later*. it wouldn't be necessary to know in advance, when to switch on, though. it seems like it is enough to add 1.5ms to each [delay] that schedules the switch-off-messages.
Ah, yes, you're right: I didn't interpret the patch correctly. Attached is another version which allows to test different delay times and also lets you compare a switched off with a non-switched signal. It shows, that timing is indeed no problem when switching off subpatches, which is good news to me.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Dec 11, 2006, at 8:38 AM, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
the attached patch shows that the subpatch is [switch~]ed off too
early, but not [switch~]ed on too late.So for tight timing switching on has to be done at least one
block *in advance*.if i interprete correctly, what your patch is telling me, then one
would have to switch *off* one block *later*. it wouldn't be necessary
to know in advance, when to switch on, though. it seems like it is enough
to add 1.5ms to each [delay] that schedules the switch-off-messages.Ah, yes, you're right: I didn't interpret the patch correctly. Attached is another version which allows to test different delay times and also lets you compare a switched off with a non-switched signal. It shows, that timing is indeed no problem when switching off subpatches, which is good news to me.
There could be a number of idle voices that are switched on to
prevent this. So you could specify, say 5 voices always ready, then
whenever one voice starts playing, it also turns on another idle voice.
This would be harder to implement, but would be a nicer outcome than
a hard-coded 1.5 ms delay.
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Mon, 2006-12-11 at 09:41 -0500, Hans-Christoph Steiner wrote:
On Dec 11, 2006, at 8:38 AM, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
the attached patch shows that the subpatch is [switch~]ed off too
early, but not [switch~]ed on too late.So for tight timing switching on has to be done at least one
block *in advance*.if i interprete correctly, what your patch is telling me, then one
would have to switch *off* one block *later*. it wouldn't be necessary
to know in advance, when to switch on, though. it seems like it is enough
to add 1.5ms to each [delay] that schedules the switch-off-messages.Ah, yes, you're right: I didn't interpret the patch correctly. Attached is another version which allows to test different delay times and also lets you compare a switched off with a non-switched signal. It shows, that timing is indeed no problem when switching off subpatches, which is good news to me.
There could be a number of idle voices that are switched on to
prevent this. So you could specify, say 5 voices always ready, then
whenever one voice starts playing, it also turns on another idle voice.This would be harder to implement, but would be a nicer outcome than
a hard-coded 1.5 ms delay.
this is quite what frank mentioned in his post before and then i was trying to explain that something like that is not necessary (respectively that there is no problem with timing, when using vline~ and such). it turned out that the end of a envelope period is cut, not the start. that is why i proposed to switch~ off a subpatch 1 block later, or in other words: when you generate an envelope with vline~ that takes e.g. 1000ms, then you should send 1001.5 (1000 + 1.5 [1block]) to the delay, that switch~es the subpatch off in order to avoid cutting the end of the envelope.
roman
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
There could be a number of idle voices that are switched on to
prevent this. So you could specify, say 5 voices always ready, then
whenever one voice starts playing, it also turns on another idle voice.
Another approach is one, that Andy is using a lot: use [env~] next to the outlet, and compare it to a userdefined level using [< X]. Then [select 1] this to [switch~] off the patch.
This is fully automatic and depending on how big you make the buffer size of [env~] it has enough delay time built in to avoid distortion in the signal. You could even fade out using [line~], if you're very cautious. The only additional cost is one [env~], but this may quickly pay off.
One could put the [env~] solution into the [polypoly-wrap] abstraction to make it completely automaic for [polypoly] but then users would be forced to do it this way and generally I don't like to enforce things like that too much in my abstractions.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sat, 9 Dec 2006, Hans-Christoph Steiner wrote:
The right inlet serves as the loadbang. You need to use the right inlet instead of regular [loadbang]s
Could this be changed so that it uses the ordinary [loadbang] ? If you have a canvas to send messages to, you can send it a "loadbang" message, which will trigger all the [loadbang]s in the canvas. Is there a reason why the canvas can't be reached (or can't be reached individually), and could this be circumvented easily?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 9 Dec 2006, Hans-Christoph Steiner wrote:
The right inlet serves as the loadbang. You need to use the right inlet instead of regular [loadbang]s
Could this be changed so that it uses the ordinary [loadbang] ? If you have a canvas to send messages to, you can send it a "loadbang" message, which will trigger all the [loadbang]s in the canvas. Is there a reason why the canvas can't be reached (or can't be reached individually), and could this be circumvented easily?
It is just there for backwards compatibility. I only reworked nqpoly4 to make it look nicer and to make further development easier. The [polypoly] abstraction that I derived from nqpoly4 doesn't need the loadbang-inlet anymore, it sends a "loadbang"-message after dynamically filling the subpatch, which, as you wrote, loadbangs all objects inside that subpatch just fine.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Dec 12, 2006, at 6:26 AM, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 9 Dec 2006, Hans-Christoph Steiner wrote:
The right inlet serves as the loadbang. You need to use the
right inlet instead of regular [loadbang]sCould this be changed so that it uses the ordinary [loadbang] ? If
you have a canvas to send messages to, you can send it a "loadbang"
message, which will trigger all the [loadbang]s in the canvas. Is there a
reason why the canvas can't be reached (or can't be reached
individually), and could this be circumvented easily?It is just there for backwards compatibility. I only reworked nqpoly4 to make it look nicer and to make further development easier. The [polypoly] abstraction that I derived from nqpoly4 doesn't need the loadbang-inlet anymore, it sends a "loadbang"-message after dynamically filling the subpatch, which, as you wrote, loadbangs all objects inside that subpatch just fine.
Since you've now written another, do you think there is a possibility
of making a nqpoly "kernel" for making poly systems with different
functionality, like the auto-[switch~] version, the instance manager
version, etc.
What I do a lot of is making a patch, then controlling many copies of
it, so I plan on making a version of nqpoly4 that works well in that
situation.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Hallo, derek holzer hat gesagt: // derek holzer wrote:
I still can't understand how to create abstractions for nqpoly and get it to call them, but at least your version looks a bit cleaner ;-)
Can you explain in simple steps how to use this patch?
Did you check out the old documentation from the CVS in abstractions/nqpoly/nqpoly4 ? There are some simple examples. Basically using nqpoly4 is easy: Only two arguments are required: The number of instances to create of an abstraction and the name of that abstraction. Additonally four more arguments may be passed, which will be creation arguments of your abstraction.
The abstraction you use must have two inlets and one outlet. The right inlet is used as a [loadbang] replacement: It will receive a bang after creation of the instance. You can ignore it if you want.
You can ignore the left inlet as well: It will receive messages you send to the first inlet of nqpoly4, but it is "voice managed". That is an incoming message will only be used by one instance, which will then eat this message and not send it along to other instances. Receiving anyhting in inlet0 will also close that instance's inlet, so no further messages are accepted until you send a bang through the outlet, which will open the inlet again.
So assuming we have an abstraction delay1000.pd:
[inlet] [inlet]
|
[del 1000]
|
| [print $0-BANG]
|
[outlet]
Then you create [nqpoly4 10 del1000]. This will create 10 instances of [delay1000]. If you send a bang into this [nqpoly4 10 del1000], you will get one message printed like: "1002-BANG: bang". If you sent another one earlier than one second you will get a different message, e.g.: "1003-BANG: bang", because the 1002-instance still is closed and another instance will respond.
As the delay will send a bang to the outlet after 1 second, all instances will open itself at some point. Then you will get e.g. the first "1002-BANG: bang" again.
The abstractions also will be called with arguments: First arg is the instance index number, second is the total number of instances (10 in the example) and then come the additional up to four arguments, that were passed to nqpoly4. (Additional args are useful for audio objects: just pass $0 as first arg, then put a [throw~ $3-dsp] into your abstraction and use a [catch~ $0-dsp] in the parent.)
See attached example for arguments in use.
So using [print $1-BANG] instead of [print $0-BANG] will make delay1000 print:
0-BANG: bang 1-BANG: bang 2-BANG: bang ...
Also, if I wanted dynamic voice handling (i.e. voices shut off when not in use to save CPU), does nqpoly handle this by itself or would I need to build a [switch~] into the abstraction?
nqpoly4 doesn't do anything specific to audio, so you would need to put a switch into your abstraction yourself. But you could use the voice allocation algorithm implemented to switch the switch.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
See attached example for arguments in use.
Just for kicks I made a dirty conversion of Risset's bell from the docs (D07.additive.pd) to use nqpoly4.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 08 Dec 2006 19:28:22 +0100 derek holzer derek@x-i.net wrote:
Hi Frank and the list,
I was searching for some help with nqpoly4 and found this from last July...
Frank Barknecht wrote:
Attached is a reworked version of nqpoly4, which should be compatible but I only tested it with your many-osc.pd so far.
I still can't understand how to create abstractions for nqpoly and get it to call them, but at least your version looks a bit cleaner ;-)
Can you explain in simple steps how to use this patch?
Also, if I wanted dynamic voice handling (i.e. voices shut off when not in use to save CPU), does nqpoly handle this by itself or would I need to build a [switch~] into the abstraction?
This is the powerful use that really makes abstractions imho. Allocation is really dynamic, so once that voice is gone so is the abstraction instance. But it never hurts to add [switch~] into a block of code to shut it down when [env~][< 1], i'm getting to do it by habit now as patches grow bigger and I struggle for CPU.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 49: "Display your talent"
I don't suppose you'd like to write it up as a short tut using a *simple* synthesiser for the "6 simple synthesisers" document? One part is to be about voice management and polyphony, so a good, easy to follow explanation of using [nqpoly4] would be very welcome.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Chris McCormick -
dafydd hughes -
derek holzer -
Frank Barknecht -
Hans-Christoph Steiner -
james tittle -
Mathieu Bouchard -
padawan12 -
Roman Haefeli