Personal tools
You are here: Home documentation developer PdMemoryModel
Views

Pure Data Memory Model

This page is under construction and intends to describe how Pd deals with memory for DSP.

Contents

  1. DSP overview

  2. Reblocking

  3. Sorting

1. DSP overview

Digital signal processing (DSP) can be understood as the act of transforming a sequence of numbers that represent a certain signal on the discrete time domain into another set of numbers, by acting upon them by means of an algorithm. The resulting structures may represent an explicit manipulation of the input signal or any other structure of information about the nature of the input signal.

A finite signal is represented as a sequence defined for all natural numbers less or equal some number N: x=x(1), ... , x(N). Every signal x has an associated sample rate R Hz, meaning that the samples x(n) occur at a fixed rate of R samples per second. This corresponds to a fixed interval of 1/R seconds between two adjacent samples.

The manipulation of x generates an output signal y. The output signal does not have to have the same sample rate as the input signal. In fact, we could up or downsample a certain signal according to some rules to obtain output signals with different sample rates.

When we consider real time DSP that generate audible signals, the output signal must also be associated with a sample rate. The simplest scenario occurs when the input and output signals have the same sample rate R. In this scenario, an output sample is always associated with an input sample, and the time between the arrival of one sample x(n) and the availability of an output sample y(n) is the delay between input and output signals. For real time purposes, the delay between input and output samples should be sufficiently small so the output occurs at the same "perceptual time" of the input. This usually menas a delay of 50ms or less.

The sample rate of the output signal also determines the maximum amount of calculation time, as the next sample must be ready to be played at at most 1/R second after the previous sample was available.

Calculations can be done on a per-sample basis or over a sequence of samples called a block. If we define a block size of B samples, this means that we will accumulate B samples before starting the processing, and will return B samples after the calculation has been made. If the (input and output) sample rate is R, then the amount of time available for the calculation of a whole block of B samples is B/R seconds.

Also, there is another common structure for digital processing which is to allow blocks to overlap with some factor o. So, if o = 2, then the second half of the first block corresponds to the first half of the second block.

2. Reblocking

Each Pd canvas may have its specific block size, block overlap and up/downsampling configurations. Signals that flow from one canvas to another may have to be adapted to fit different canvases configurations. Depending on the relation between cofigurations of one specific subcanvas and its containing canvas, DSP computation on the subcanvas will happen with a super- or submultiple frequency of the containing canvas.

Reblocking/switching.

DSP scheduling inside a canvas with reblocked signal has the following structure:

  1. inlet and outlet prologue code.

  2. block prologue.

  3. the objects in the subcanvas, including inlets and outlets.

  4. block epilogue.

  5. outlet epilogue code.

The sample rate inside a canvas is defined in relation to its parent canvas's sample rate:

srate = parent_srate * realoverlap * upsample / downsample;

The calling frequency for a canvas's DSP group of routines is given by

frequency = (parent_vecsize * realoverlap * upsample)
            / (vecsize * downsample);

Unstructured notes

From Pd source code:

/* The "block~ object maintains the containing canvas's DSP computation,
calling it at a super- or sub-multiple of the containing canvas's
calling frequency.  The block~'s creation arguments specify block size
and overlap.  Block~ does no "dsp" computation in its own right, but it
adds prolog and epilog code before and after the canvas's unit generators.

A subcanvas need not have a block~ at all; if there's none, its
ugens are simply put on the list without any prolog or epilog code.

Block~ may be invoked as switch~, in which case it also acts to switch the
subcanvas on and off.  The overall order of scheduling for a subcanvas
is thus,

  1.  inlet and outlet prologue code (1)
  2.  block prologue (2)
  3.  the objects in the subcanvas, including inlets and outlets (2)
  4.  block epilogue (2)
  5.  outlet epilogue code (2)

where (1) means, "if reblocked" and  (2) means, "if reblocked or switched".

If we're reblocked, the inlet prolog and outlet epilog code takes care of
overlapping and buffering to deal with vector size changes.  If we're switched
but not reblocked, the inlet prolog is not needed, and the output epilog is
ONLY run when the block is switched off; in this case the epilog code simply
copies zeros to all signal outlets.

block~ object state

  • size of audio signals in this block.

  • number of samples actually to compute.

  • window overlapping factor.

  • from 0 to period-1; when zero we run the block.

  • submultiple of containing canvas.

  • supermultiple of comtaining canvas.

  • number of times parent block has called us.

  • beginning of code in DSP chain.

  • length of dspchain for this block.

  • length of epilog.

  • true if we're acting as a a switch.

  • true if we're switched on.

  • true if inlets and outlets are reblocking.

  • upsampling-factor.

  • downsampling-factor.

  • stop right after this block (for one-shots).

d_ugen routines

vinlet_dspprolog voutlet_dspprolog voutlet_dspepilog

struct _block



Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser