[crash] VST3 editor deadlocks and crashes via Tao/WebView2 conflict

[yungchoppa]

What happened?

On Windows, opening and closing complex VST3 plugin GUI editors (e.g., Tokyo Dawn Records TDR Nova) causes direct instability:

1. The plugin window either freezes or turns completely black after a short moment.
2. Closing the plugin editor or stopping the audio pipeline triggers an immediate application crash (0xC0000005 Access Violation in ntdll.dll).

Root Cause Analysis

Running VST3 editors in-process alongside Tauri 2 (WebView2 / Tao event loop) triggers core platform conflicts:

• Event Loop Interference: Tao and WebView2 capture the Windows message loop, starving JUCE-based plugins of standard WM_TIMER dispatching needed for rendering and UI state updates.
• Heap & COM Collisions: Destructing plugin resources during slot recycling or pipeline teardown conflicts with WebView2's DirectComposition and heap allocator (RtlpFreeHeap).
• Threading Deadlocks: JUCE binds GUI initialization to the main thread; off-thread calls freeze on juce::MessageManagerLock.

Steps to reproduce

1. Launch Splitwave on Windows.
2. Add an audio source and insert a complex VST3 plugin node (e.g., TDR Nova).
3. Open the plugin GUI editor window.
4. Observe the interface freezing or blacking out after initial render.
5. Close the plugin editor window or stop the audio pipeline/remove the node.

Expected behavior

The VST3 GUI editor should render continuously at 60 fps without freezing, and closing the editor or stopping/reconfiguring the audio pipeline should not crash the host process.

App version

v1.1.0

Operating system

Windows

OS version

25H2

Additional context

Proposed Solution: Out-of-Process Plugin Bridge

To eliminate crashes and provide a clean 60 fps Win32 rendering environment, I developed an Out-of-Process hosting architecture for Windows:

• Dedicated Helper: Minimal runner spawned via splitwave.exe --plugin-bridge <session_id> running a pure Win32 message loop without any webview overhead.
• Low-Latency Audio IPC: SPSC ring buffer communication across Windows Shared Memory (CreateFileMappingW / MapViewOfFile) with atomic sequence tracking (<0.1 ms latency).
• Control Channel: Thread-safe synchronization for parameter automation, state sync, and window toggle (SW_HIDE / SW_SHOW).
• View Lifecycle Safety: Safe IPlugView caching (take_view) preventing use-after-free conditions during editor probing.

Scope of Changes

• src-tauri/src/audio/plugins/bridge/: Bridge runner, shared memory audio IPC, and messaging protocol (#[cfg(target_os = "windows")]).
• src-tauri/src/audio/plugins/vst3_host.rs: Safe IPlugView handling.
• src-tauri/src/audio/plugins/registry.rs: Dispatch Windows VST3 nodes to BridgeHost.
• src-tauri/src/main.rs: Early command-line dispatch for --plugin-bridge prior to webview init.
• src-tauri/Cargo.toml: Enable Win32_System_Memory Windows sys features.

Verification

• Tested on Windows 11 with TDR Nova.
• Confirmed stable real-time spectrum drawing at 60 fps, zero-latency parameter updates, and crash-free pipeline stops.
• Non-Windows platforms remain completely unaffected.

I have already implemented and verified this solution locally. If this approach fits the project architecture, I can submit the Pull Request for review.

[Horuse]

Thank you for taking the time to report this issue.

I tested Tokyo Dawn Records TDR Nova on macOS and was able to reproduce the same behavior: a black screen and crashes. This confirmed that the issue is cross-platform and not specific to Windows or Tao/WebView2.

After a detailed investigation of Splitwave's host code and crash logs, I determined that this is not an architectural limitation of in-process hosting. Instead, it is caused by a combination of issues related to lifecycle management, thread affinity, and native plugin window handling. Some of these root causes also overlap with the scanning issue reported in #34.

The main issues identified are:

1. Incorrect IPlugView lifecycle during pipeline rebuilds.
   The old and new editor views could briefly exist at the same time, causing the teardown of the old view to interfere with the timers, graphics context, and message-loop hooks of the new one.

2. Race condition involving createView(kEditor).
   Under certain timing conditions between take_view() and has_editor(), two IPlugView instances could be created for the same plugin. This breaks the expected lifecycle of JUCE-based VST3 editors and can result in black screens or crashes.

3. Main-thread affinity violations when working with plugin bundles.
   Scanning, module descriptor handling, and plugin library loading/unloading could occur on background threads. For plugins using JUCE, Qt, or Cocoa, this can lead to access violations and unstable lifecycle behavior. This issue is also related to [crash] Crash when scanning Native Instruments plugins for plugin node #34.

4. Native editor window lifecycle and compositing issues.
   An incorrect sequence of hide/show, focus, invalidation, and embedding operations could leave the editor window in an invalid state, including a black screen after reopening.

5. Re-entrant locking and event-loop issues during close/reopen.
   Interactions between native window events, plugin host callbacks, and internal locks could lead to deadlocks or UI freezes when closing and reopening an editor window.

[Horuse]

I’ve now been able to fully resolve the issue on macOS (#37). Unfortunately, I’m unable to verify the same fix on Windows because TDR Nova does not currently provide a Windows ARM64 build, so I can’t run it in my Windows environment.

I also tried building and testing several other open-source JUCE-based VST3 plugins for Windows ARM64, but none of them reproduce the crashes seen with TDR Nova on the current main branch.

Since you already have an environment where the issue can be reproduced on Windows, I’d really appreciate it if you could test my fix with TDR Nova and let me know whether it resolves the crashes and editor issues on your side as well.

Thank you again for taking the time to investigate this and for working on the PR. Your testing and feedback have been very helpful.

If the fix doesn’t fully resolve the issue on Windows, I’ll take a closer look at your approach as a possible Windows-specific workaround or as a basis for any additional platform-specific handling that may still be needed.

[yungchoppa]

Hi @Horuse,

I tested PR #37 on Windows 11 (x86_64) with Tokyo Dawn Records TDR Nova as well as several other VST3 plugins.

Here are the verification results:

• Plugin Scanning: Scans smoothly without access violations or UI hangs (main-thread affinity fixes are working as expected).
• Editor GUI Rendering: Opens immediately with full graphical interface rendered (no black screen).
• Real-time Performance: The 60 fps spectrum analyzer and UI animations run continuously and do not freeze.
• Reopen Lifecycle: Tested repeated open/close cycles (10+ times) — window hides and reveals reliably without COM/Direct2D crashes.
• Pipeline Teardown: Stopping the audio pipeline or removing the node while the editor is open closes the window cleanly without host crashes.

The in-process lifecycle and thread affinity refactoring in #37 completely resolves the issue on Windows as well! 🎉

---

Minor observations / notes for Windows:

1. Window sizing (white borders on bottom/right):
   In src-tauri/src/audio/plugins/editor.rs, set_content_size adds decoration_overhead (dw, dh) to window.set_size(). Because window.set_size() in Tauri 2 operates on the inner (content) size, adding decoration margins makes the client area slightly larger than the plugin's requested size, leaving a small white stripe at the bottom and right edge. Setting LogicalSize::new(w, h) directly matches the plugin geometry cleanly on Windows.

2. Windows build note (svelte.config):
   On Windows, Node.js failed to import svelte.config.ts during bun run check / vite dev (ERR_UNKNOWN_FILE_EXTENSION). Renaming svelte.config.ts to svelte.config.js resolves this for Windows development.

---

Since #37 resolves the root causes in-process cleanly across all platforms, feel free to close my PR #36 in favor of this one (or keep it as reference if out-of-process sandboxing is ever explored in the future).

Thank you for the thorough investigation and fix!