Reply to thread

Message: [QUOTE="Queen, post: 90499, member: 27"] BUFFR holds up to 120 minutes of your computer's own audio output on a lane of its own, separate from anything your DAW plays. That lane sits alongside the plugin's DAW audio slots and its MIDI capture, so a browser tab, a standalone synth, or a video call all land in the same history you already scroll through. No routing setup. No second recorder running in the background. Producers have spent years solving this with virtual audio drivers, pushing the operating system's output into a fake input device and wiring it back around. It works, mostly. It also breaks every time you swap interfaces, update your OS, or lose track of which device is selected. One limit is worth knowing before anything else. BUFFR only keeps what happened while it was loaded and running, so it cannot reach back and rescue the demo you played before you opened the session. The desktop lane is audio only. Notes you play on a controller land on the MIDI side, where [B][URL='https://goldmidi.com/community/threads/matari-audio-expanded-buffr-beta-with-smart-quantize.75917/']the Smart Quantize pass added in 0.6.53[/URL][/B] can straighten the timing later. [HEADING=2]Each system hands over the sound in its own way[/HEADING] On Windows there is no device picker at all. BUFFR follows whatever your default output device happens to be, through a built-in loopback path, with no helper app and no background service to install. Change that default mid-session and the capture follows it. macOS 13 and later works differently. The plugin runs a bundled helper for as long as system audio capture is active, and the first time you switch it on, macOS asks for Screen Recording permission. That prompt looks wrong for an audio tool. It isn't. Screen Recording is the permission Apple keeps desktop sound behind, so refusing it leaves you with a lane that stays flat forever. Linux uses PipeWire directly and mixes up to 16 application streams down to stereo. It also leaves the DAW host family out on purpose, and that exclusion is the part doing you a favor. Without it, [B]capturing whatever your speakers are playing[/B] would fold your own session back into the recording and double everything you hear. [HEADING=2]A silent lane usually points at a permission[/HEADING] Check the lane status first. If the meter never moves on macOS, the Screen Recording grant is almost always the reason, and toggling it in System Settings then reloading the plugin clears it. On Linux, confirm you actually have a PipeWire session running rather than a bare ALSA setup. Windows misses are usually a routing accident instead. Capture follows the default output, so anything your operating system sends somewhere else never reaches the lane. Point the sound you want at the default output, and it shows up. Placement matters less here than people expect. System audio arrives on its own path rather than through the track feeding the plugin, so an instance on the master picks up desktop sound the same way a track instance does. For a wide safety net, the master with capture set to Always is the least fussy setup. [HEADING=2]Desktop capture stays on until you turn it off[/HEADING] System audio is enabled by default, which is a design choice worth knowing now rather than discovering later. Every notification, every video, every half-listened podcast goes into the buffer while the plugin runs. If your desktop output includes things you would rather not retain, switch the lane off in settings. Everything stays on your machine. Capture, playback, editing, processing, and export all happen locally, and no audio leaves the computer. Network access covers activation, updates, and any problem report you choose to send There is one honest limitation left. The lane is a stereo mix of whatever the OS is playing, so a video call and a reference track running together arrive as a single blended signal with no way to pull them apart afterward. Pause what you don't need before you play the thing you do. [/QUOTE]

Name