Example I01.Fourier.analysis.pd (Figure 9.14, part a) demonstrates computing the
Fourier transform of an audio signal using the `fft~` object:

:
Fast Fourier transform. The two inlets take audio signals representing the real
and imaginary parts of a complex-valued signal. The window size is given
by Pd's block size. One Fourier transform is done on each block.

The Fast Fourier transform [SI03] reduces the computational cost of
Fourier analysis in Pd to only that of between 5 and 15 `osc~` objects in
typical configurations. The FFT algorithm in its simplest form takes to
be a power of two, which is also (normally) a constraint on block sizes in Pd.

Example I02.Hann.window.pd (Figure 9.14, parts b and c) shows how to control the
block size using a `block~` object, how to apply a Hann window, and a
different version of the Fourier transform. Part (b) shows the invocation of a
subwindow which in turn is shown in part (c). New objects are:

:
real Fast Fourier transform. The imaginary part of the input is assumed to
be zero. Only the first channels of output are filled in (the others
are determined by symmetry). This takes half the computation time of the
(more general) `fft~`object.

:
repeatedly outputs the contents of a wavetable. Each
block of computation outputs the same first samples of the table.

In this example, the table ``$0-hann" holds a Hann window function
of length 512, in agreement with the specified block size. The signal
to be analyzed appears (from the parent patch) via the `inlet~` object.
The channel amplitudes (the output of the `rfft~` object) are reduced
to real-valued magnitudes: the real and imaginary parts are squared separately,
the two squares are added, and the result passed to the `sqrt~` object.
Finally the magnitude is written (controlled by a connection not shown in
the figure) via `tabwrite~` to another table, ``$0-magnitude", for
graphing.

Example I03.resynthesis.pd (Figure 9.15) shows how to analyze and resynthesize an audio signal following the strategy of Figure 9.7. As before there is a sub-window to do the work at a block size appropriate to the task; the figure shows only the sub-window. We need one new object for the inverse Fourier transform:

:
real inverse Fast Fourier transform. Using the first points of its
inputs (taken to be a real/imaginary pair), and assuming the appropriate values
for the other channels by symmetry, reconstructs a real-valued output. No
normalization is done, so that a `rfft~`/`rifft~` pair together
result in a gain of . The `ifft~` object is also available
which computes an unnormalized inverse for the `fft~` object,
reconstructing a complex-valued output.

The `block~` object, in the subwindow, is invoked with a second argument
which specifies an overlap factor of 4. This dictates that the sub-window will
run four times every samples, at regular intervals of 128 samples. The
`inlet~` object does the necessary buffering and rearranging of samples
so that its output always gives the 512 latest samples of input in order. In
the other direction, the `outlet~` object adds segments of
its previous four inputs to carry out the overlap-add scheme shown in Figure
9.7.

The 512-sample blocks are multiplied by the Hann window both at
the input and the output. If the `rfft~` and `rifft~` objects
were connected without any modifications in between, the output would
faithfully reconstruct the input.

A modification is applied, however: each channel is multiplied by a (positive real-valued) gain. The complex-valued amplitude for each channel is scaled by separately multiplying the real and imaginary parts by the gain. The gain (which depends on the channel) comes from another table, named ``$0-gain". The result is a graphical equalization filter; by mousing in the graphical window for this table, you can design gain-frequency curves.

There is an inherent delay introduced by using `block~` to increase
the block size (but none if it is used, as shown in Chapter 7, to reduce
block size relative to the parent window.) The delay can be measured from
the inlet to the outlet of the sub-patch, and is equal to the difference of the
two block sizes. In this example the buffering delay is 512-64=448 samples.
Blocking delay does not depend on overlap, only on block sizes.