Two hours of stereo audio at 48 kHz in 32-bit float works out to roughly 2.8 GB of memory, before your sample libraries take a single byte.
Nobody sets that number deliberately. You see a history length slider, you drag it to the end, and the plugin gets on with the job. The cost turns up later, in a session that goes sluggish for no obvious reason.
Double the sample rate, and you double the bill. At 96 kHz, the same two hours want about 5.5 GB. Run a sixteen-channel history instead of a stereo one, and you are asking for something near 22 GB, which is more memory than most machines have spare with a real session loaded. The appeal of a rolling record of everything your machine played is that you never decide in advance what mattered, and that convenience gets paid for in resident memory, inside the host's own address space, competing with every instrument you have open.
Well-built capture allocates in short pages instead of reserving the whole window up front. A one-second page gets filled, sealed, and kept. If the page turned out to be silent, it gets thrown away.
That changes the arithmetic for how most people work. Plenty of any session is you listening, reading, and thinking, and none of that puts audio on the captured lane. The buffer tracks activity rather than wall clock time.
It also means the number moves around. Ten minutes of continuous playback costs more than an hour of intermittent tinkering, so the same setting behaves differently on a mixing day than on a writing day.
Set the window against the machine you have. How much memory a session really needs is dominated by sample libraries, and a capture buffer competes with them directly in the same process. On a 16 GB laptop, thirty minutes of stereo history runs about 700 MB, which is nothing worth worrying about. Load an orchestral template on 64 GB, and the two-hour setting has to justify 2.8 GB against instruments you are already playing.
A typical implementation holds tens of thousands of interpreted events per instance, with much smaller ceilings on raw and UMP streams, often a few thousand each. Those limits are per instance, not per project.
Ordinary playing never gets close. A busy sixteen-bar part is a few hundred events.
Expressive controllers are the exception. MPE sends continuous pitch, pressure, and slide data on its own channel for every finger, and a few minutes of that will drain a budget that would otherwise cover hours of straight keyboard parts. The time window stops mattering at that point. Oldest events drop, and your ninety-minute history is functionally a ten-minute one
Check what your controller actually emits before you trust the number on the slider. Continuous data from a ribbon, a breath controller, or a touch surface arrives at a rate that ordinary note entry never reaches.
Continuous capture is worthless if a host crash takes the history with it, so recovery data gets written to disk every few seconds. That needs a working reserve, and a couple of gigabytes is a normal amount to set aside.
The reserve is separate from your project folder. It does not shrink because you cleared the buffer, and on a laptop already tight on space it is enough to matter.
Checkpointing has a granularity worth knowing about. Whatever happened since the last write is gone, so a crash costs you the last few seconds no matter how long the history is. That gap stays fixed at a few seconds whether you set the window to five minutes or two hours, which makes it the one part of the design that gets proportionally cheaper the more history you keep.
Nobody sets that number deliberately. You see a history length slider, you drag it to the end, and the plugin gets on with the job. The cost turns up later, in a session that goes sluggish for no obvious reason.
Double the sample rate, and you double the bill. At 96 kHz, the same two hours want about 5.5 GB. Run a sixteen-channel history instead of a stereo one, and you are asking for something near 22 GB, which is more memory than most machines have spare with a real session loaded. The appeal of a rolling record of everything your machine played is that you never decide in advance what mattered, and that convenience gets paid for in resident memory, inside the host's own address space, competing with every instrument you have open.
The buffer only grows when there is sound
Those figures are the ceiling, not the reading you will actually see.Well-built capture allocates in short pages instead of reserving the whole window up front. A one-second page gets filled, sealed, and kept. If the page turned out to be silent, it gets thrown away.
That changes the arithmetic for how most people work. Plenty of any session is you listening, reading, and thinking, and none of that puts audio on the captured lane. The buffer tracks activity rather than wall clock time.
It also means the number moves around. Ten minutes of continuous playback costs more than an hour of intermittent tinkering, so the same setting behaves differently on a mixing day than on a writing day.
Set the window against the machine you have. How much memory a session really needs is dominated by sample libraries, and a capture buffer competes with them directly in the same process. On a 16 GB laptop, thirty minutes of stereo history runs about 700 MB, which is nothing worth worrying about. Load an orchestral template on 64 GB, and the two-hour setting has to justify 2.8 GB against instruments you are already playing.
MIDI runs out of events before it runs out of time
Note data is cheap in bytes and expensive in count, so it gets capped differently.A typical implementation holds tens of thousands of interpreted events per instance, with much smaller ceilings on raw and UMP streams, often a few thousand each. Those limits are per instance, not per project.
Ordinary playing never gets close. A busy sixteen-bar part is a few hundred events.
Expressive controllers are the exception. MPE sends continuous pitch, pressure, and slide data on its own channel for every finger, and a few minutes of that will drain a budget that would otherwise cover hours of straight keyboard parts. The time window stops mattering at that point. Oldest events drop, and your ninety-minute history is functionally a ten-minute one
Check what your controller actually emits before you trust the number on the slider. Continuous data from a ribbon, a breath controller, or a touch surface arrives at a rate that ordinary note entry never reaches.
Crash recovery takes disk, not memory
The other cost sits on your drive, and it is easy to miss.Continuous capture is worthless if a host crash takes the history with it, so recovery data gets written to disk every few seconds. That needs a working reserve, and a couple of gigabytes is a normal amount to set aside.
The reserve is separate from your project folder. It does not shrink because you cleared the buffer, and on a laptop already tight on space it is enough to matter.
Checkpointing has a granularity worth knowing about. Whatever happened since the last write is gone, so a crash costs you the last few seconds no matter how long the history is. That gap stays fixed at a few seconds whether you set the window to five minutes or two hours, which makes it the one part of the design that gets proportionally cheaper the more history you keep.
