A bad plug-in should not be allowed to become a bad broadcast.
VST3 plug-ins are native code. OBS Safe VST3 Host changes the failure boundary by keeping third-party VST3 DSP and vendor GUI code outside obs64.exe in both the Single Host and VST3 Rack workflows.
The core boundary
What isolation does
- Single Host runtime: third-party VST3 DSP and vendor GUI run in
obs-safe-vst3-host.exe. - Rack runtime: Rack VST3 DSP, Rack Editor, persistence work and vendor-editor ownership live in
obs-safe-vst3-rack-host.exe. - Scanning: normal candidate probing is performed outside OBS.
- Recovery: helper health, state restoration and bounded restart behavior are explicit product concerns.
What happens to audio when an isolated result is unavailable?
The realtime OBS side is designed around bounded work. If a valid processed wet block is late, invalid or unavailable, the product keeps the original dry/pass-through audio instead of deliberately waiting without bound.
During a live show, losing an effect is preferable to intentionally stalling the broadcast audio callback.
Durable working-Rack recall
Each OBS VST3 Rack filter has its own durable working-session state. This is separate from named reusable Rack presets: the user does not need to create a preset merely to preserve the Rack they were actively using before closing OBS.
The working session stores topology, bypass state and VST3 component/controller state using CRC-protected atomic writes with a last-known-good recovery path.
DSP-safe state capture
Vendor state capture is control-plane work, but third-party VST3 implementations are not all safe to call concurrently with realtime process(). The Rack establishes a bounded capture frontier before calling vendor getState.
- new Rack vendor processing calls fail dry while capture is active;
- the control owner waits only for already-running vendor calls to leave;
- the Rack DSP path does not wait on a control mutex;
- filesystem and state serialization work remain outside the OBS audio callback.
Dry-first restore
A saved Rack may contain third-party plug-ins whose open/state-restore time is slow or variable. The helper therefore becomes safely available with a dry/empty generation first. The saved chain materializes on the control owner and replaces the working generation only when the complete restored chain is coherent.
Split controller/processor VST3 state
Some VST3 plug-ins keep their native editor/controller and processor as distinct components. The Rack uses a bounded control-to-DSP bridge for native editor edits and supports controller-wide resync when a plug-in reports parameter values changed.
Before state capture, accepted controller edits must cross that processor frontier so the saved state represents the actual sound, not just controller metadata.
Storage failure is not hidden
If the per-Rack durable storage path cannot be created or resolved, the product does not present a normal writable Rack as successfully persistent. It stays dry and reports Needs Attention.
Named presets remain independent
Named Rack presets continue to provide reusable user-managed chains. Missing Rack plug-ins can remain pass-through placeholders, and a failed/corrupt preset load is not allowed to replace the current working Rack.
Can this promise OBS will never crash?
No. Windows, OBS itself, drivers, hardware faults and other native components remain outside this project's control. The defensible claim is architectural: third-party VST3 runtime and vendor UI code are deliberately kept outside the OBS process.
Crash isolation is not a malware sandbox
The helper processes run with your Windows user permissions. A malicious VST3 can still use APIs and resources available to your account.
Unsigned Windows package
The current package is not commercially Authenticode-signed. Windows may show Unknown publisher or a SmartScreen reputation warning. Do not disable Windows security globally.
Use the installer button below. It resolves the latest official public release automatically; SHA256SUMS.txt remains available for integrity verification.