Tags: posts articles Plugins Sound Design Spectral Processing Ambient

PaulXStretch and the Paulstretch Algorithm Explained

Article | Jul 07, 2026

PaulXStretch is not just another granular time-stretching plugin. It is built around the Paulstretch algorithm, which stretches sound in the frequency domain, discards phase information, rebuilds the signal with randomized phase, and turns short recordings into wide, slow, spectral textures.

PaulXStretch is a plugin and standalone application for extreme time stretching and spectral sound design. It is based on Paul's Extreme Sound Stretch, originally created by Nasca Octavian Paul, and on the PaulXStretch version by Xenakios. The current PaulXStretch project makes this sound available as a modern plugin with a redesigned interface, DAW integration, capture, freeze, and additional spectral modules.

PaulXStretch

The important thing to understand is this: PaulXStretch is not meant to behave like a transparent time-stretching algorithm. It is not the right tool if you want to correct timing, preserve a vocal phrase, or keep drum transients punchy. It is designed for radical transformation. It can take a short sample and turn it into a long ambient texture, drone, pad, noise bed, shimmer, or spectral wash.

That special sound comes from the Paulstretch algorithm itself.

What PaulXStretch Is

PaulXStretch reads incoming audio or an audio file, analyzes it in overlapping windows, transforms each window into the frequency domain, manipulates the spectrum, and then reconstructs the sound. In practical terms, this means it works more like a spectral resynthesis instrument than a conventional sampler effect.

The plugin includes the main stretch engine plus extra controls for pitch shift, frequency shift, freeze, onset detection, frequency spread, harmonics, tonal-vs-noise processing, filtering, compression, and a drawable free filter. In the source code, this extra processing is handled in the ProcessedStretch layer, where the spectrum can be passed through modules such as harmonics, tonal-vs-noise, frequency shift, pitch shift, ratio mix, spread, filter, compressor, and free filter before being turned back into audio.

This is why the plugin feels different from many normal granular effects. It is not only repeating small slices of audio. It is working on the frequency content of the sound itself.

The Core Idea

The Paulstretch algorithm can be simplified into this process:

  1. Take a long window of audio.
  2. Apply a window function so the edges fade smoothly.
  3. Run an FFT to convert the audio into a spectrum.
  4. Keep the magnitude of each frequency bin.
  5. Throw away the original phase information.
  6. Optionally process the spectrum.
  7. Rebuild the sound with randomized phase.
  8. Overlap and crossfade the reconstructed windows.
  9. Move through the source audio very slowly.

The key step is phase randomization.

In the PaulXStretch source code, the FFT class is described as an FFT class that considers phases as random. The forward transform function is commented as taking samples to frequencies while phases are discarded. The inverse function is commented as taking frequencies back to samples while phases are random. You can see this directly in the project's Stretch.h and Stretch.cpp.

This is the heart of the sound.

Why Phase Matters

Audio is not only a list of frequencies. It is also timing. The phase of each frequency component tells you where that component sits inside the waveform. If you preserve phase carefully, you can keep attacks, waveform shape, stereo detail, and transient structure more intact.

Paulstretch does not try to preserve that structure. It keeps the spectral energy but lets go of the exact waveform timing. The result is that the sound keeps a memory of its frequency content, but loses much of its original shape in time.

This is why a voice can still feel like a voice, but no longer behaves like a normal recording. The formants, resonances, and broad spectral shape may still be there, but the articulation is dissolved. A piano note can still carry the harmonic identity of a piano, but the hammer attack is smeared into a slow cloud. A drum loop can turn into a noisy, evolving texture instead of a rhythm.

The sound becomes less like playback and more like a spectral afterimage.

How This Is Different From Granular Stretching

Granular time stretching usually works in the time domain. A plugin cuts the source into many small grains, then replays those grains with different timing, overlap, pitch, position, density, jitter, and envelopes. This can create clouds, freezes, stutters, textures, or smooth time stretching depending on the implementation.

Paulstretch also uses windows, but the important transformation happens after the audio is converted into the frequency domain. It does not simply scatter tiny audio snippets. It analyzes a chunk of sound, keeps the magnitude spectrum, randomizes phase, and resynthesizes the result.

That difference changes the character:

This is also why Paulstretch is not great for subtle correction. Many modern time-stretching algorithms are designed to preserve musical timing, transients, and pitch perception. Paulstretch is more interesting because it does not try to stay invisible.

Why It Sounds So Smooth

The smoothness comes from a combination of long analysis windows, overlap-add reconstruction, and randomized phase.

With very large windows, the algorithm sees a broad slice of the sound at once. This gives it a detailed frequency picture, but poor time precision. Attacks and small rhythmic gestures are averaged into the larger window. When those windows are reconstructed and overlapped, the output becomes continuous and slow-moving.

The randomized phase also prevents the reconstruction from locking back into the exact waveform shape of the source. Instead of hearing a stretched copy of the original waveform, you hear a resynthesized version of its spectrum. This reduces the obvious "looped grain" feeling that can happen in some granular patches.

The cost is that sharpness disappears. But for ambient music, pads, drones, spectral beds, and sound design, that loss is often the whole point.

Onsets And Freeze

PaulXStretch also includes onset detection and freeze behavior. Onset detection is useful because extreme stretching can make every transient smear into everything around it. The code compares spectral energy changes between frames and can reset timing behavior around stronger onsets. This helps the stretch engine react to sudden changes instead of treating the whole file as one flat continuum.

Freeze is the natural extension of the same idea. If the input position stops moving, the plugin keeps producing output from the current spectral state. Since the reconstruction is not just a small looping waveform, the result can feel like a suspended texture rather than a short loop.

For sound design, this is one of the most useful parts of the plugin. You can search for a small moment in a recording, freeze it, then shape it with filtering, harmonics, spread, or pitch/frequency shifting.

The Extra Spectral Modules

PaulXStretch is more than the original stretch algorithm wrapped in a plugin. It adds a chain of spectral processors that operate on the frequency bins before the sound is reconstructed.

Some important modules:

For developers, this is an important design point. Once the sound is represented as magnitudes per frequency bin, many operations become simple array operations. You can smooth the spectrum, shift bins, scale certain bands, draw envelopes over frequency, emphasize peaks, remove noisy regions, or create artificial harmonic profiles. Then the inverse FFT turns that edited spectrum back into sound.

A Rough Developer Mental Model

If you wanted to build something in the same family, the basic mental model would look like this:

input audio
  -> collect a large analysis window
  -> apply window function
  -> FFT
  -> magnitude = sqrt(real^2 + imag^2)
  -> discard phase
  -> process magnitude spectrum
  -> generate random phase per bin
  -> real = magnitude * cos(random_phase)
  -> imag = magnitude * sin(random_phase)
  -> inverse FFT
  -> overlap-add / crossfade with previous output
  -> advance source position by a very small amount

The stretch factor mostly controls how slowly the read position moves through the input compared to how much output is generated. If the read position advances very slowly, a short sound can become minutes or hours long.

The FFT size is not just a quality setting. It is part of the instrument. Smaller FFT sizes react faster and can sound more unstable or grain-like. Larger FFT sizes smear time more strongly and create the classic large, slow, spectral pad sound. PaulXStretch exposes this because the window size strongly affects the musical result.

Why It Is Special

Paulstretch is special because it embraces a tradeoff that many time-stretching algorithms try to avoid.

Most time stretchers ask: how can we change duration while preserving the original sound?

Paulstretch asks: what happens if we preserve the broad spectrum and abandon the original timing detail?

That one decision creates the identity of the algorithm. It destroys transient precision, but creates a stable, beautiful, slow spectral world. It does not preserve the original performance in a clean way, but it can reveal hidden resonances inside a sound. It does not behave like a transparent tool, but it is excellent as a creative one.

This makes it useful for:

Practical Use In A DAW

In Bitwig or any other DAW, I would treat PaulXStretch as a sound source or resampling tool rather than an insert effect for correction. Load a short recording, stretch it heavily, find a useful region, freeze or loop it, then print the result to audio.

Good sources are usually rich but not too busy:

After recording the output, the stretched result can be edited like any other sample. Cut the best parts, fade them, pitch them, layer them under a track, or feed them into another sampler or spectral processor.

Sources And Further Reading