[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