Chronos

Chronos is a stereo VST3 convolution plugin. It takes audio in, an impulse response (IR) loaded from a WAV file, and produces the audio convolved with that IR.

It does this end-to-end in 64-bit double precision — including the FFT itself, not just the input and output buffers. Most convolution plugins use single-precision (float32) FFT internally because most FFT libraries are float-only; for short IRs and reverb work, that's fine. For long-tap precision work — room correction filters with 100,000+ taps, active-speaker correction, audiophile playback — single-precision accumulates measurable numerical error. Chronos uses the marton78 fork of pffft's double-precision branch, with SIMD acceleration, throughout.

The convolution engine is non-uniform partitioned: small head blocks for low latency near the start of the impulse, doubling block sizes for the tail. The head block size is exposed as a user-controllable parameter — a direct latency vs CPU tradeoff that other convolvers usually hide. You pick it; Chronos reports the exact latency to the host for plugin delay compensation.

The product surface is intentionally narrow: load an IR, set a head block size, optionally normalize, and listen. The technical work is the engine, not the UI.

• Insert Chronos on a stereo bus or track.
• Click Browse... and select a WAV impulse response. Mono or stereo, any sample rate from 44.1k to 192k.
• Read the file-info line below the browser: it confirms the IR's sample rate, total taps, duration, channel layout, and whether resampling is happening.
• Choose a Head Block Size. Smaller = lower latency, more CPU. The default 64 is a sensible starting point (≈1.45 ms at 44.1 kHz).
• Listen. The latency readout at the bottom of the UI tells you exactly how many samples Chronos is adding to the chain.

The "Loaded" indicator turns green when the audio thread has picked up the new IR. Until then, audio passes through unprocessed.

The right side of the UI shows the loaded impulse response in the time domain. Horizontal axis is time; vertical axis is amplitude. For a typical room correction IR you'll see an initial spike followed by smaller reflections decaying over time. For a longer reverb-style IR you'd see decay across the whole window.

The display is a quick sanity check — confirms the IR loaded as expected and gives you a visual sense of its energy distribution.

Below the file picker, four pieces of metadata are shown:

• Sample rate — the WAV file's native rate
• Taps — total length in samples
• Duration — in milliseconds
• Channel layout — mono or stereo

Below that, two more lines tell you how Chronos is handling the file:

• Multi-rate set — if the WAV contains IRs at multiple rates, the available rates are listed and the active one highlighted. "native, no resampling" indicates Chronos is using the IR at its natural rate; otherwise it tells you which rate is being resampled to host rate via r8brain-free-src.
• Peak / Normalization — the IR's maximum sample value in dBFS, plus the active normalization mode. Useful for predicting output level.

The bottom status bar shows the current Latency (in samples and milliseconds — this is what's reported to the host), CPU usage, and a Loaded indicator that turns green when the audio thread is processing through the loaded IR.

For each input block:

• Audio enters the head-block buffer in double precision.
• When the head block is full, the first partition is convolved via overlap-save with a double-precision FFT.
• Subsequent partitions run in their own block sizes (doubling schedule) on a worker pipeline, contributing to the output buffer at the right time offsets.
• Output is mixed, Output Trim is applied, and the buffer is returned to the host.

The convolution uses non-uniform partitioning following Gardner (1995) with refinements by Garcia (2002) and Wefers (2014). The first N samples are convolved at the head block size; the next 2N at 2N; the next 4N at 4N; and so on through doublings until the full IR length is covered. This minimizes the latency contribution (which is the head block size) without paying the CPU cost of running the entire convolution at the smallest block size.

The FFT engine is pffft's double-precision branch (marton78 fork) with AVX and NEON SIMD acceleration. Most convolution plugins use single-precision FFT because most FFT libraries are float-only. For short IRs that's fine. For long IRs (tens of thousands of taps), single-precision arithmetic accumulates numerical error — measurable in the magnitude response, audible on critical material. Double-precision gives a numerical floor near 10⁻¹⁶ instead of 10⁻⁷; the CPU cost is roughly 1.5–2× over a comparable float implementation.

Hot-swap engine: when you load a new IR, the worker thread builds the partitioned convolver in the background and pushes a pointer through a lock-free SPSC queue (moodycamel readerwriterqueue). The audio thread does a single atomic pointer swap on the next block boundary. No allocations, no locks, no deletes on the audio thread. The "Loaded" indicator only turns green when the audio thread has actually picked up the new filter — not when the worker has finished building it.

Chronos can load your filter at its native sample rate, with no resampling, giving you the exact frequency response you designed at every rate you run your host at. This section explains how to set it up.

Why it matters

When a filter designed at one sample rate is played at a different host rate, it has to be resampled. Chronos uses r8brain-free-src at maximum quality — a well-respected polyphase resampler — but resampling can never perfectly reconstruct a filter's response across rates. An upsampled correction filter shows small high-frequency deviations from the design target that, while usually inaudible on music, show up clearly on a measurement.

If instead you give Chronos a copy of your filter exported natively at each rate you use, it loads the matching one directly. No resampling, no deviation — the response is exactly what you designed.

How to set it up

Step 1. In your filter-design tool — rePhase, REW, Acourate, Audiolense, or any other — export the same filter once per sample rate you actually run your host at. If you only ever play at 48 kHz, you don't need this feature; a single file is fine. If you switch between 44.1 kHz and 96 kHz, export the filter at both.

Step 2. Name the files with the sample rate in Hz, with an underscore, right before the .wav extension:

myfilter_44100.wav      ← 44.1 kHz version
myfilter_48000.wav      ← 48 kHz version
myfilter_88200.wav      ← 88.2 kHz version
myfilter_96000.wav      ← 96 kHz version

The part before _<rate> — here, myfilter — is the base name, and it must be identical across the set. Put the files in the same folder.

Step 3. In Chronos, Browse... to any one of the files. Chronos parses the rate suffix, looks in the same folder for siblings sharing the base name, and assembles the set. The file-info area then shows which rates are available and which one is active for your host:

Multi-rate set: 44.1k / 48k / 88.2k / 96k.  Using 96k (native, no resampling).

The word "native" is the reward — it means your filter is being convolved at the exact rate it was designed for, with no sample-rate conversion in the path.

Supported rate suffixes

Use the integer sample rate in Hz. The standard suffixes Chronos recognizes:

• 44100 — 44.1 kHz
• 48000 — 48 kHz
• 88200 — 88.2 kHz
• 96000 — 96 kHz
• 176400 — 176.4 kHz
• 192000 — 192 kHz

Use the integer Hz form rather than a kHz shorthand like 44k1 or 96k — the integer form is unambiguous and matches the file's actual sample rate header.

Fallback behavior

If you load a single file with no rate suffix (e.g., just room.wav), Chronos treats it as rate-agnostic: it'll be resampled to host rate via r8brain-free-src if needed, exactly like a single-file workflow always has. The multi-rate feature is purely additive — existing single-file projects continue to work unchanged.

If you load a multi-rate file but no sibling matches the host rate (e.g., you have 44.1k/48k/96k and the host is running at 88.2k), Chronos resamples from the closest available rate via r8brain-free-src and discloses it:

Multi-rate set: 44.1k / 48k / 96k.  Resampled from 96k → 88.2k via r8brain.

Edge cases & validation

Chronos validates that the files in a set are plausibly the same filter — matching channel count and matching duration. If a sibling file doesn't match (e.g., you accidentally have myfilter_44100.wav as stereo and myfilter_48000.wav as mono), Chronos ignores the mismatched file with a warning rather than loading it by mistake. Better to silently drop a problem file than to surprise the audio chain with the wrong topology.

Live host sample-rate changes are handled: if you save a project at 48 kHz and reopen it at 96 kHz, Chronos re-resolves the multi-rate set against the new host rate automatically — you get the native 96 kHz file if you have one, or graceful resampling otherwise.

Practical tips

• rePhase: regenerate the same correction with each "Output Sample Rate" you need and save with the rate suffix.
• REW: export your filter from the filter list at each rate, or use REW's IR generation at the target rate. Add the suffix on save.
• Acourate: export the filter at each rate you need; rename with the suffix afterwards.
• You don't need every standard rate — only the ones you actually use. Two or three rates is typical (44.1k for music, 48k for video, plus a high-rate option if your DAC supports it).
• The base name is purely a label — call it anything that helps you keep filter sets organized. livingroom_v3_44100.wav works just as well as filter_44100.wav.

Room correction

Load a measured room correction IR generated by REW, Acourate, Audiolense, Dirac, or any other measurement tool. Chronos handles long IRs (up to 262,144 taps — about 5.95 seconds at 44.1 kHz) without latency surprises because the head block size is your choice. Drop into a hi-fi playback chain, an active-speaker rig, or a mastering reference path.

Active-speaker correction

Apply per-driver correction filters in a multi-way system. The natural workflow is Chronos-inside-MetaHost: one Chronos instance per channel pair (or per driver in some configurations), each loaded with the correction IR for its band. The non-uniform partitioning shines here because you can pick a small head block to keep monitoring chains responsive.

IR-based EQ

Design an arbitrary frequency response (in REW, MATLAB, Octave, custom Python, or any FIR design tool), convert to taps, save as WAV, load into Chronos. Linear-phase or minimum-phase EQ at arbitrary precision. The double-precision engine matters here: long-tap FIR designs benefit from the lower numerical floor.

Vintage hardware impressions

Load IRs captured from analog hardware (mic preamps, console paths, tape machine paths, mastering buses). Pair with Helios for the nonlinear character. Together they cover the linear and nonlinear halves of "make digital sound like analog."

Audiophile playback

Drop Chronos on a hi-fi playback chain to apply room correction without owning a hardware convolver. Runs inside JRiver, MetaHost, or any VST3 host. The double-precision engine isn't just marketing here — for long correction IRs the precision is measurable.

Chronos is designed to live alongside the rest of the Pataki Audio catalog. The natural pairings:

• Janus — linear-phase crossover (analytical filter design, used live for splitting bands)
• Voicing — Baxandall-style musical tonal balancing per band
• Helios — asymmetric SET-style nonlinear warmth (memoryless waveshaper)
• Chronos — linear coloration via IRs (room correction, captured hardware, designed EQ curves)
• MetaHost — routes all the above across multichannel speaker buses
• Bitscope — verifies bit-depth and true peak at any stage

Helios + Chronos is the natural pair for "vintage gear" coloration: Helios for the nonlinear character (memoryless asymmetric saturation), Chronos for the linear part (impulse responses captured from analog hardware). Together they cover both halves of recreating a particular analog flavor in the digital domain.

Chronos-inside-MetaHost for active-speaker correction: load a different correction IR per stereo pair, each tuned to a different driver band. MetaHost routes; Chronos corrects.

Why does this exist when there are many convolvers already?

Most VST3 convolvers are reverb-focused and use single-precision FFT. Float is fine for reverb because reverb tails forgive numerical noise. Float is not fine for room correction with 100k+ taps and strict precision requirements — error accumulates audibly. Standalone room-correction convolvers exist (Acourate Convolver, JRiver's built-in engine), but none of them are VST3 plugins — which limits their use inside DAWs and VST3-aware playback chains. Chronos fills that gap: VST3, double-precision throughout, designed for correction work and audiophile playback.

What head block size should I use?

Smaller = lower latency, higher CPU. Larger = higher latency, lower CPU. For tracking/monitoring chains where round-trip latency matters, use 32–64 (≤1.5 ms). For mixing or playback chains, 256–1024 is fine and saves CPU. The plugin won't choose for you — you know your use case.

Can I use Chronos as a reverb?

Sure. Any IR can be a reverb IR. But Chronos is overkill for reverb — most dedicated reverb convolvers work in float and sound identical for reverb material. Save the CPU and use one of those.

My IR is at a different sample rate than my host. What happens?

Chronos resamples on load via r8brain-free-src and shows you the resampling notice. r8brain is a well-respected high-quality polyphase resampler — no audible artifacts. If you load a multi-rate WAV that contains a native-rate IR, Chronos picks that natively and the notice tells you so.

Does normalization affect the audio if turned off?

No. Off means the IR is convolved at exactly the gain it has in the WAV file. Output Trim is your manual gain handle. For measurement-driven correction work, leaving normalization Off and trusting the measurement is usually the right move.

How long can my IR be?

262,144 taps maximum. That's about 5.95 seconds at 44.1 kHz, 1.36 seconds at 192 kHz. Room correction IRs are typically 32k–131k taps. Reverb IRs can be much longer — for those, use a dedicated reverb plugin.

Can it process multichannel audio?

Chronos is stereo. For multichannel (surround, active speakers), use Chronos inside MetaHost — one Chronos instance per channel pair, each with its own IR. That's the workflow MetaHost was built for.

Is the double-precision claim actually audible?

For most material, no. For long-tap room correction filters with deep magnitude response, the difference is measurable in the frequency domain and occasionally audible on the lowest reaches of dynamic content. Most importantly, double-precision is correct — it removes a class of numerical error from being a factor at all, so you don't have to wonder whether what you're hearing is the IR or the engine's noise floor.

Does Chronos affect transient response?

Chronos is a linear, time-invariant convolution — it does exactly what the IR says, including the IR's own transient handling. If you load a minimum-phase IR, transient attack is preserved. If you load a linear-phase IR, pre-ringing comes with the IR (not from Chronos). Chronos is the engine; the IR is the character.

Chronos exists because of a specific gap in the plugin ecosystem. The VST3 convolvers that exist are almost entirely reverb-focused (Altiverb, Liquidsonics, MConvolutionEZ, etc.); the few that aren't typically compromise on precision or partitioning. Standalone applications for room correction (Acourate Convolver, JRiver's built-in engine) exist but are not VST3, which means they can't run inside a DAW chain or any host that wants a VST3 plugin slot.

The technical core is pffft's double-precision branch (the marton78 fork). pffft is a well-respected SIMD-optimized FFT library; the double-precision branch keeps the same architecture and SIMD acceleration but operates on doubles. The combination — non-uniform partitioned convolution, double-precision FFT, SIMD — produces a numerical floor near 10⁻¹⁶ at a CPU cost roughly 1.5–2× a comparable float convolver. Acceptable for the use case; the precision is what justifies the plugin's existence.

The non-uniform partitioning follows the Gardner (1995) doubling scheme with refinements from Garcia (2002) and Wefers (2014). The user-controllable head block size is unusual — most convolvers auto-pick. But for plugins-inside-plugins (Chronos-inside-MetaHost) and for the wide range of use cases Chronos targets, the user typically knows the right latency to target. Exposing the parameter respects that.

The hot-swap engine uses moodycamel's readerwriterqueue (lock-free SPSC). The audio thread never allocates, never deletes, never locks. Filter pointer atomic-swaps at block boundaries. The "Loaded" indicator only flips green when the audio thread has confirmed the new filter is live — a small honesty in the UI that matters when you're testing IR changes back-to-back.