Performance

Granular synthesis is CPU-hungry. Field spawns a stream of short grains, and each one is separate work for the processor. This page explains what drives that load and how to bring it down when your device struggles.

What drives CPU

The cost of the grain engine tracks how many grains are sounding at once and how much each one has to do.

Grain density. Density sets how often new grains fire. More grains per second means more simultaneous voices to read, window, and pitch-shift. This is the largest single driver of CPU on the grain engine. If the audio starts to crackle, lower Density first.

Grain size. Size sets how long each grain lasts. Longer grains overlap more, so at a given density more grains are alive at the same moment. Larger sizes therefore raise the number of simultaneous grains and the cost with it. Pulling Size down shortens each grain and thins the overlap.

Density and Size interact. You can reach the same "thick" sound from high density with short grains or lower density with long grains; the second costs less. When you need to save CPU, favour fewer, shorter grains.

You can drive both from the same places in the UI: the MAIN panel has dedicated Density and Size dials, and the GRAINS X/Y box maps Density against Size for two-thumb performance. Either surface changes the same engine parameters.

The grain-cloud display

The live grain cloud on the play surface is drawn with a Metal renderer. Every grain is one instanced quad, additively blended, and the whole cloud is a single draw call per frame. It reads a lock-free snapshot of the grains on the UI thread and never touches the audio thread, so the visualization does not compete with the audio for the real-time render path.

The renderer scales with the number of grains it draws, which is the same thing that drives audio cost: a denser cloud is more instances to draw and more grains to synthesize. Lowering Density and Size lightens both at once.

Sample rate and buffer

The standalone engine runs at 44.1 kHz with a 512-sample block size by default. In an AUv3 host, the host owns the audio configuration, so buffer size and sample rate come from the host's audio settings rather than from Field. Larger host buffers lower CPU load at the cost of more latency; raise the host buffer if you hear dropouts during dense passages.

Practical tuning

When the audio glitches or the device runs hot, work through these in order:

1. Lower Density on the MAIN panel or the GRAINS box.
2. Lower Size so grains overlap less.
3. In an AUv3 host, raise the host's audio buffer size.

Each step reduces the number of grains alive at once, which is what the engine and the grain-cloud renderer both pay for.