BUFFR allocates audio in one-second RAM pages as capture happens, rather than reserving the full two hours up front, and it discards silent channels outright. That design decides everything about the footprint. An idle session sitting on a quiet track barely registers, while a dense sixteen-channel history running the whole window consumes a serious amount of memory.
Sixteen slots is the ceiling on the DAW side, arranged as a stereo Main plus seven stereo Aux pairs, with the system audio lane sitting outside that count. Fill all of them, and you are asking the machine to hold sixteen channels of continuous audio for as long as you set the window. Most people do not need that. Most people never check.
The window itself runs anywhere from one minute to 120, and it is the first lever worth touching. Ten minutes catches almost every "wait, play that again" moment without asking much of anything. Two hours is for the days you know you will forget what you did.
Silent channels being discarded matter more than it sounds. If your Aux pairs are routed but idle, they are not quietly eating memory in the background while you work on something else. The cost tracks what you played, not what you plumbed in.
Pulling material out does not add to the load either. The non-destructive cleanup pass in 0.6.53 runs inside the plugin's own buffer rather than through your DAW's signal path, so tidying a recovered take is not a second recording sitting somewhere.
For ordinary keyboard playing, that is a lot of history. For dense MPE work, aftertouch sweeps, or a controller streaming continuous data, it is not. Slide and pressure gestures generate events at a rate that ordinary note playing never approaches, so an expressive controller can fill the ring well before the window you selected has elapsed.
The practical result is that a player working on an MPE surface has a shorter effective memory than the setting implies, and no warning that it happened. If your workflow leans on expression rather than notes, treat the ring size as the real limit and drag important material out sooner rather than later.
Recovery is tied to instance identity rather than to the plugin generally. Reopen the same saved plugin instance or project state, and it can reclaim that identity and restore its last complete checkpoint. Open a fresh instance instead, and there is nothing to reclaim.
The gap between checkpoints is the honest limitation. If the host dies abruptly, you lose roughly the uncheckpointed tail, which is a few seconds of the most recent material. That is a good trade against losing everything, and it is worth knowing before you assume a crash costs you nothing.
The memory cost of a long capture window is easiest to manage by matching it to how you actually work. A composer running a single instrument through a ten-minute window will never notice the plugin. Someone tracking a band across every Aux pair with the full 120 minutes selected should keep a system monitor open, because that is the exact configuration where the demand turns substantial.
Sixteen slots is the ceiling on the DAW side, arranged as a stereo Main plus seven stereo Aux pairs, with the system audio lane sitting outside that count. Fill all of them, and you are asking the machine to hold sixteen channels of continuous audio for as long as you set the window. Most people do not need that. Most people never check.
The window itself runs anywhere from one minute to 120, and it is the first lever worth touching. Ten minutes catches almost every "wait, play that again" moment without asking much of anything. Two hours is for the days you know you will forget what you did.
The buffer only grows into what you actually record
Because pages are allocated as sound arrives, the capture mode you pick changes the bill directly. Always keeps recording continuously through the selected window, which is the widest net and the heaviest one. On sound starts at an audio threshold with a configurable tail, so gaps between takes stop consuming pages, and MIDI carries on recording underneath the threshold regardless. Manual only captures while the record control is armed.Silent channels being discarded matter more than it sounds. If your Aux pairs are routed but idle, they are not quietly eating memory in the background while you work on something else. The cost tracks what you played, not what you plumbed in.
Pulling material out does not add to the load either. The non-destructive cleanup pass in 0.6.53 runs inside the plugin's own buffer rather than through your DAW's signal path, so tidying a recovered take is not a second recording sitting somewhere.
MIDI runs out of events before it runs out of minutes
The MIDI side works on a completely different budget, and this is the part that surprises people. Instead of scaling with the window, it uses fixed rings, holding 32,768 interpreted events, 4,096 raw events, and 4,096 UMP events. Whatever you set the minutes to, those numbers do not move.For ordinary keyboard playing, that is a lot of history. For dense MPE work, aftertouch sweeps, or a controller streaming continuous data, it is not. Slide and pressure gestures generate events at a rate that ordinary note playing never approaches, so an expressive controller can fill the ring well before the window you selected has elapsed.
The practical result is that a player working on an MPE surface has a shorter effective memory than the setting implies, and no warning that it happened. If your workflow leans on expression rather than notes, treat the ring size as the real limit and drag important material out sooner rather than later.
Checkpoints protect the take, not the whole history
Roughly every five seconds, BUFFR writes a crash-recovery checkpoint covering retained audio, MIDI, and jam markers. That is a separate copy on disk, not a scheme for pushing older history out of RAM, and it needs 2 GiB of free disk kept in reserve to work.Recovery is tied to instance identity rather than to the plugin generally. Reopen the same saved plugin instance or project state, and it can reclaim that identity and restore its last complete checkpoint. Open a fresh instance instead, and there is nothing to reclaim.
The gap between checkpoints is the honest limitation. If the host dies abruptly, you lose roughly the uncheckpointed tail, which is a few seconds of the most recent material. That is a good trade against losing everything, and it is worth knowing before you assume a crash costs you nothing.
The memory cost of a long capture window is easiest to manage by matching it to how you actually work. A composer running a single instrument through a ten-minute window will never notice the plugin. Someone tracking a band across every Aux pair with the full 120 minutes selected should keep a system monitor open, because that is the exact configuration where the demand turns substantial.
