I understood that the name stands for 'not quite poly', but I wanted to know if somebody has tried to overcome this nqpoly4 limitation: as far as I've understood it, the abstraction created via nqpoly receive it's voice number as the first creation argument, but it's not possible to send a message from the calling patch to a specific voice.
This is essential if I want to make a true midi controlled polyphonic synth. In fact I need the abstraction to receive noteoffs and start the release part of the envelope.
Now, as I'm writing, I've thought about a solution. To put the [noteout] object inside the abstraction. In this way you can [select] the voice and act only if it is the same of the abstraction instance. I haven't tested it but it should work.
So my question to the list has changed: what about adding an example of this technique to the npqoly distribution?
Frank?
Ciao,
c.
Cesare Marilungo wrote:
I understood that the name stands for 'not quite poly', but I wanted to know if somebody has tried to overcome this nqpoly4 limitation: as far as I've understood it, the abstraction created via nqpoly receive it's voice number as the first creation argument, but it's not possible to send a message from the calling patch to a specific voice.
This is essential if I want to make a true midi controlled polyphonic synth. In fact I need the abstraction to receive noteoffs and start the release part of the envelope.
Now, as I'm writing, I've thought about a solution. To put the [noteout] object inside the abstraction.
[notein], not noteout, sorry.
In this way you can [select] the voice and act only if it is the same of the abstraction instance. I haven't tested it but it should work.
So my question to the list has changed: what about adding an example of this technique to the npqoly distribution?
Frank?
Ciao,
c.
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
I understood that the name stands for 'not quite poly', but I wanted to know if somebody has tried to overcome this nqpoly4 limitation: as far as I've understood it, the abstraction created via nqpoly receive it's voice number as the first creation argument, but it's not possible to send a message from the calling patch to a specific voice.
This is possible. The additive synth bell example I posted shows one way how to address each instance seperatly. You get the voice number as first argument so you can do various things with it inside the poly-abstraction.
Another example is attached, which is more traditional and is built around [poly]. Both approaches don't use the voice allocation of nqpoly4 at all: Nobody forces you to use it, and I generally don't use it anyways.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
I understood that the name stands for 'not quite poly', but I wanted to know if somebody has tried to overcome this nqpoly4 limitation: as far as I've understood it, the abstraction created via nqpoly receive it's voice number as the first creation argument, but it's not possible to send a message from the calling patch to a specific voice.
This is possible. The additive synth bell example I posted shows one way how to address each instance seperatly. You get the voice number as first argument so you can do various things with it inside the poly-abstraction.
Another example is attached, which is more traditional and is built around [poly]. Both approaches don't use the voice allocation of nqpoly4 at all: Nobody forces you to use it, and I generally don't use it anyways.
Ciao
I missed that. But the attached patch does what I was trying to do.
Cool!
And much easier than I though. Of course, everything is easy if somebody with more experience show you how to do it.
Thanks.
Ciao,
c.
#N canvas 441 361 419 206 10; #X obj 227 75 inlet; #X obj 273 75 inlet; #X obj 226 114 outlet; #X text 212 53 we don't need this; #X obj 75 66 r $3-notes; #X obj 75 97 route $1; #X obj 75 131 print $1_NOTE; #X connect 4 0 5 0; #X connect 5 0 6 0;
#N canvas 0 0 648 359 10; #X obj 74 88 random 127; #X msg 74 65 bang; #X obj 74 113 makenote 80 1000; #X obj 74 148 pack 0 0; #X obj 74 178 poly 8; #X obj 74 227 s $0-notes; #X obj 74 203 pack 0 0 0; #X obj 157 179 nqpoly4 9 polytest $0; #X text 163 155 9 = 8 + 1! [poly] starts counting at 1 , nqpoly doesn't! ; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 2 1 3 1; #X connect 3 0 4 0; #X connect 4 0 6 0; #X connect 4 1 6 1; #X connect 4 2 6 2; #X connect 6 0 5 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
Frank Barknecht wrote:
This is possible. The additive synth bell example I posted shows one way how to address each instance seperatly. You get the voice number as first argument so you can do various things with it inside the poly-abstraction.
Another example is attached, which is more traditional and is built around [poly]. Both approaches don't use the voice allocation of nqpoly4 at all: Nobody forces you to use it, and I generally don't use it anyways.
I missed that. But the attached patch does what I was trying to do.
Cool!
Actually you've made me think that it would be a good idea to have an inlet in nqpoly4 for data as produced by the [poly] object. Then one wouldn't need to make the send/receive pair by hand. Currently nqpoly4 implements one voice allocation algorithm which is a bit limited and only really useful for granular synthesis, but not so useful for Midi-inspired polyphony, where the note length isn't known in advance.
I think, a successor of nqpoly4 should not care about voice allocation at all by itself.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
I think, a successor of nqpoly4 should not care about voice allocation at all by itself.
Actually, in the end what I'm looking for is exactly dynamic voice allocation, so that I can get PD to act like SuperCollider and only let abstractions create a CPU load when they are actually being played, instead of all the time. The granular synthesis work I'm doing is just too heavy otherwise. I'd hoped nqpoly would do that, but I'm still not sure. Maybe it's just a way of spawning a bunch of abstractions at once, regardless how heavy they run...
d.
Derek Holzer wrote:
Frank Barknecht wrote:
I think, a successor of nqpoly4 should not care about voice allocation at all by itself.
Actually, in the end what I'm looking for is exactly dynamic voice allocation, so that I can get PD to act like SuperCollider and only let abstractions create a CPU load when they are actually being played, instead of all the time. The granular synthesis work I'm doing is just too heavy otherwise. I'd hoped nqpoly would do that, but I'm still not sure. Maybe it's just a way of spawning a bunch of abstractions at once, regardless how heavy they run...
d.
Maybe I can answer here: even if you need to do granular synthesis, nqpoly takes the right approach.
Basically, when you create the nqpoly4 object with the number of abstractions you need, it actually instantiates them at the time of its creation. This is preferable, since allocating new instances at granular rate would be even more cpu heavy. So it is better to allocate the maximum simultaneous number of instances from the beginning. Especially during a live performance.
In csound, for instance, when you use it in realtime, voice are allocated when they're needed, on the fly (I'm not sure but I believe it doesn't deallocate them until the end of the performance). This could result in audio glitches unless the sample buffer is big enough (so you have more latency). In fact there's an opcode (an instruction in csound) to preallocate n voices for a given instrument.
Ciao,
c.
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
Maybe it's just a way of spawning a bunch of abstractions at once, regardless how heavy they run...
Yes, nqpoly4 is just a way of spawing a bunch of abstractions with arguments, connecting their first in/outlets in series and bang-ing their second inlet on creation. It's nothing more and nothing less.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Dec 9, 2006, at 10:01 PM, Derek Holzer wrote:
Frank Barknecht wrote:
I think, a successor of nqpoly4 should not care about voice
allocation at all by itself.Actually, in the end what I'm looking for is exactly dynamic voice
allocation, so that I can get PD to act like SuperCollider and only
let abstractions create a CPU load when they are actually being
played, instead of all the time. The granular synthesis work I'm
doing is just too heavy otherwise. I'd hoped nqpoly would do that,
but I'm still not sure. Maybe it's just a way of spawning a bunch
of abstractions at once, regardless how heavy they run...
[nqpoly4] will allocate the given number of voices. Then you can
control the CPU using a [switch~] in the replicated abstraction.
Whenever that abstraction receives a message, it would first turn on
[switch~], then execute the message. Then after sending the
"complete" bang, it would turn off the [switch~]. That should cover it.
.hc
¡El pueblo unido jamás será vencido!
Frank Barknecht wrote:
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
Frank Barknecht wrote:
This is possible. The additive synth bell example I posted shows one way how to address each instance seperatly. You get the voice number as first argument so you can do various things with it inside the poly-abstraction.
Another example is attached, which is more traditional and is built around [poly]. Both approaches don't use the voice allocation of nqpoly4 at all: Nobody forces you to use it, and I generally don't use it anyways.
I missed that. But the attached patch does what I was trying to do.
Cool!
Actually you've made me think that it would be a good idea to have an inlet in nqpoly4 for data as produced by the [poly] object. Then one wouldn't need to make the send/receive pair by hand. Currently nqpoly4 implements one voice allocation algorithm which is a bit limited and only really useful for granular synthesis, but not so useful for Midi-inspired polyphony, where the note length isn't known in advance.
I think, a successor of nqpoly4 should not care about voice allocation at all by itself.
In fact I was trying to the same thing using nqpoly4 voice allocation, but I wasn't thinking that there's no gain in using it for this kind of purpose. In fact the abstraction are all instantiated when the nqpoly4 object is created and the bang to the abstraction outlet only tells nqpoly4 which voice has been freed.
Anyway I've modified your example to make some sounds and I've noticed a problem. If I edit my voice abstraction and then I use the nqpoly4 right inlet to reset and reload the abstraction, then one of the voice becomes silent. I've not understood completely nqpoly4 inner workings but I guess this is due to the fact that we make it create one more instances (eg. [nqpoly4 9 ... ] with [poly 8].
This problem is solved by using the same number for both [nqpoly4] and [poly] and adding a [- 1] between the poly first outlet and pack first inlet.
I've attached the patches.
Ciao,
c.
Ciao
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
This problem is solved by using the same number for both [nqpoly4] and [poly] and adding a [- 1] between the poly first outlet and pack first inlet.
Ah, of course: [- 1]!! I'm embarrassed. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
I think, a successor of nqpoly4 should not care about voice allocation at all by itself.
In fact I was trying to the same thing using nqpoly4 voice allocation, but I wasn't thinking that there's no gain in using it for this kind of purpose. In fact the abstraction are all instantiated when the nqpoly4 object is created and the bang to the abstraction outlet only tells nqpoly4 which voice has been freed.
Maybe you like the little variation of nqpoly4 that I made and attached. I called it [polypoly] and it's a kind of mix between [nqpoly4] and [poly] intended to simplify traditional "midi"-like polyphony in Pd.
You use it almost like [poly], but additionally you pass the name of an abstraction. From then on it does everything for you: it creates the abstractions, connect in- and outlets, where the outlets are signal outlets now.
The abstraction to "polyphonize" just needs one inlet for (note velocity)-pairs, one inlet for loadbang, and two signal outlet~s for left and right audio channel.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
I think, a successor of nqpoly4 should not care about voice allocation at all by itself.
In fact I was trying to the same thing using nqpoly4 voice allocation, but I wasn't thinking that there's no gain in using it for this kind of purpose. In fact the abstraction are all instantiated when the nqpoly4 object is created and the bang to the abstraction outlet only tells nqpoly4 which voice has been freed.
Maybe you like the little variation of nqpoly4 that I made and attached. I called it [polypoly] and it's a kind of mix between [nqpoly4] and [poly] intended to simplify traditional "midi"-like polyphony in Pd.
You use it almost like [poly], but additionally you pass the name of an abstraction. From then on it does everything for you: it creates the abstractions, connect in- and outlets, where the outlets are signal outlets now.
The abstraction to "polyphonize" just needs one inlet for (note velocity)-pairs, one inlet for loadbang, and two signal outlet~s for left and right audio channel.
Ciao
Thanks, I'll try it.
c.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
Thanks, I'll try it.
Cool. I've made some further changes which make polypoly a bit more useful. I removed the need to have an inlet as a loadbang replacement in the polypoly-abstractions that are automatically created. Loadbangs can now be used just like in any other abstraction.
Then I reused the existing right inlet of the polypoly-abstractions as an inlet to customize it. The inlet is connected to polypoly's middle inlet now. (I guess I will remove the third inlet ot [polypoly] as it's not useful with [poly] because you cannot change the polyphony of [poly] with a message anyway).
I think, this now is a really useful approach to make traditional and even some not so traditional approaches to polyphony easy in Pd. (Yes, Hans, it will go to CVS soon. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Dec 10, 2006, at 6:25 PM, Frank Barknecht wrote:
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
Thanks, I'll try it.
Cool. I've made some further changes which make polypoly a bit more useful. I removed the need to have an inlet as a loadbang replacement in the polypoly-abstractions that are automatically created. Loadbangs can now be used just like in any other abstraction.
Then I reused the existing right inlet of the polypoly-abstractions as an inlet to customize it. The inlet is connected to polypoly's middle inlet now. (I guess I will remove the third inlet ot [polypoly] as it's not useful with [poly] because you cannot change the polyphony of [poly] with a message anyway).
I think, this now is a really useful approach to make traditional and even some not so traditional approaches to polyphony easy in Pd. (Yes, Hans, it will go to CVS soon. ;)
Oh wait, aren't I suppose to nag here? Hmm, now I don't know what to
say! ;)
I vote for a more descriptive name, like [poly_allocate] or
[poly_voices] or something...
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__ <polypoly.tgz> _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
-
Cesare Marilungo -
Derek Holzer -
Frank Barknecht -
Hans-Christoph Steiner