[PD] overcome nqpoly4 limitations

Cesare Marilungo cesare at poeticstudios.com
Sun Dec 10 05:29:08 CET 2006


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.

-- 
http://www.cesaremarilungo.com





More information about the Pd-list mailing list