When a plugin crashes
A plugin crash can’t take down your session, because every plugin runs in its own process, separate from the app and from every other plugin. When one crashes, the rest of the session keeps playing, the crashed plugin’s process restarts automatically, its state restores from the last save, and a notification tells you what happened. No lost work, no force-quit.
You got a crash notification
The notification names the plugin that went down, and by the time you read it, the recovery already happened. The crash stayed inside that plugin’s own process: the rest of the session kept playing, including a recording in progress, the process restarted automatically, and its state restored from the last save. Usually there’s nothing to do. If the same plugin crashes repeatedly, bypass it for the session and report it to its vendor.
A plugin’s sound cut out for a moment
That was the restart. A crashed plugin’s audio drops out for the moment it takes its process to come back, then returns with the last saved settings. Nothing else in the session is interrupted.
A plugin was excluded at launch
A plugin that crashes or hangs while being scanned is excluded automatically, because scanning runs in a separate process, so the app never freezes at startup. The plugin isn’t hidden: it appears in the browser labeled with its exclusion reason.
The three layers
- At scan time: plugins are scanned in a separate process at launch; one that misbehaves is excluded, not loaded.
- At load time: each plugin gets its own process, so memory leaks, CPU spikes, and crashes stay contained to that one plugin.
- At run time: a crash mid-session triggers an automatic restart and state restore while everything else keeps playing.
Why this matters
Process isolation turns “a beta plugin might end my session” into “a beta plugin might briefly restart.” Experimental effects, old favorites, unstable builds: none of them put the session at risk.