Your plugin crashes because CEF (Chromium Embedded Framework) is failing to initialize properly. The debug log shows it's trying to schedule CEF initialization, but then crashes.
Your currently installed plugin HAS a working fallback UI built into it! We just need to tell it CEF failed so it uses the fallback.
The plugin actually has fallback UI code. Just wait ~15 seconds after opening it. It should show a basic JUCE interface instead of crashing.
If you have an older build of the plugin from before CEF was added, use that.
- Open Visual Studio 2022
- Open the solution file:
C:\Wingman\Wingman.sln(if it exists) - Or create it:
cd C:\Wingman
mkdir build_manual
cd build_manual
cmake .. -G "Visual Studio 17 2022" -A x64- Open
Wingman.slnin Visual Studio - Right-click
Wingman_VST3project → Properties - C/C++ → Preprocessor → Preprocessor Definitions
- Change
CEF_AVAILABLE=1toCEF_AVAILABLE=0 - Build → Build Wingman_VST3
- Copy:
build_manual\Wingman_artefacts\Release\VST3\Wingman.vst3toC:\Program Files\Common Files\VST3\
The crash is happening because:
- CEF requires specific initialization order
- OSR (Off-Screen Rendering) mode needs the handler to persist
- CEF DLLs might not be delay-loaded properly
- DAW security restrictions might block CEF's subprocess
We need to either:
- Fix CEF initialization (complex, requires debugging)
- Use JUCE's built-in WebView instead of CEF (simpler, less features)
- Use a native JUCE UI instead of React (most stable)
Let me know if you want:
- A: Help building in Visual Studio manually
- B: A completely native JUCE UI (no CEF/React)
- C: Debug the CEF crash properly
For now, your UI changes ARE applied to the files, they're just not rendering because the plugin crashes before showing them.