pd internals (was Re[2]: [PD] switcher?)

pix pix at test.at
Fri Jun 6 12:46:12 CEST 2003

On Fri, 6 Jun 2003 11:51:05 +0200
Tim Blechmann <TimBlechmann at gmx.net> wrote:

> > Try to solve the problem within pd, there are several ways, and some
> > are even better as matrix~, because you save CPU when generators are
> > switched off.
> > If you do it that way, you will not only have the problem solved, but
> > you will get the understanding of how PD works.
> i understand your approach to minimize the use of externals. but i
> have a few general questions about how pd works:
> - dsp cycles: if i have a complex calculation that requires several pd
>   objects, will it take several dsp cycles (one for each object) or is
>   it calculated at once. eg, if i have an abstraction that does 100
>   calculations (one after another) when i send a bang, would it take
>   100 dsp cycles? 

every calculation happens "immediately", if it takes too long to
calculate, then you will get drop-outs. 

in more detail, audio is calculated in blocks. each block is by default 64
samples long. if you are generating audio at 44.1khz, then this gives you
about 1.45ms to generate each block. in general, all of the objects in
your patch have to finish their work within this time.

.. hmm, actually this isn't based on looking at the pd externals, it's
just how dsp software normally works. maybe this is wrong ;)
> - how can you switch of the calculation of some generators /
>   subpatches / patches? (i would really need this in my patches)

switch~ can turn of dsp calculation for a subpatch. for message
calculations, you just need to disable any metros, etc.

> - abstractions vs externals: i suppose externals would be faster (if
>   you want you could even write your external in the assembler
>   language of your machine), but require more ram (more code, maybe
>   larger classes)... is this correct?

i doubt that there is any such expense for externals. certainly they can
be more efficient than the equivalent abstraction. but it's worth trying
to solve any problems in pd where possible because it's easiser to test
things out quickly.


More information about the Pd-list mailing list