COMPLETE REWRITE to proper solution:
- Plugin runs in Helper process (crash-safe, like v0.2)
- GUI renders in Helper via CARemoteLayerServer
- PluginBridge.vst3 displays it via CARemoteLayerClient (CALayer inside its own editor)
- Mach port transferred via NSMachBootstrapServer (named port per PID)
- Mouse/keyboard events forwarded from host → helper via Unix socket IPC
- Audio routes via shared memory (same as v0.2)
This gives BOTH crash safety AND GUI inside Ableton's window (including fullscreen).
Based on: Apple's CARemoteLayerServer/Client public API (macOS 10.7+)
Reference: krevis/RemoteLayerDemo on GitHub"
fix: Blocklist path corrected to ~/Library/PluginBridge/ (where JUCE actually writes)"
The bare executable doesn't work — JUCE needs the .app bundle structure
(Info.plist etc.) to initialize the message loop and plugin formats.
Fix: copy entire PluginBridgeHelper.app into .vst3/Contents/Resources/
and spawn via the MacOS/PluginBridgeHelper path inside it.
Bug 1: paths with spaces got split by tokenizer. Fix: join all args after --test.
Bug 2: some plugins need the JUCE message loop to finish loading (VST3 validation).
Fix: use a Timer to delay quit, giving the plugin time to initialize.
add FAILED-APPROACHES.md — log of everything that didn't work and why
COMPLETE REWRITE — new approach:
- Plugin loads IN-PROCESS (inside Ableton) like SnappySnap
- GUI shows inside PluginBridge's own editor (no separate window)
- Helper process ONLY used to test if a plugin is safe before loading
- Blocklist persists to disk — unsafe plugins greyed out
- Shared memory / semaphores / audio routing via IPC all removed
Files changed:
- Source/Plugin/PluginBridgeProcessor.h (new: in-process hosting)
- Source/Plugin/PluginBridgeProcessor.cpp (new: direct processBlock)
- Source/Plugin/PluginBridgeEditor.h (new: embeds plugin GUI)
- Source/Plugin/PluginBridgeEditor.cpp (new: resizable, embedded editor)
- Source/Plugin/McpServer.h (simplified: talks to processor directly)
- Source/Plugin/McpServer.cpp (simplified: no helper dependency)
- Source/Plugin/Blocklist.h (NEW: persistent blocklist)
- Source/Plugin/PluginTestRunner.h (NEW: spawns helper to test-load)
- Source/Plugin/PluginTestRunner.cpp (NEW)
- Source/Helper/main.cpp (simplified: test mode only)
- Sourc…
update SYNC.md — real fix pushed (setAlwaysOnTop + X button working)
Root cause: commit 0632681 removed setAlwaysOnTop(true) and replaced it
with manual objc_msgSend level tricks. Those tricks don't keep the window
in the same Space as Ableton when fullscreen.
Fix: put back setAlwaysOnTop(true) + keep the X button fix (closeButtonPressed
hides window instead of quitting). Removed all objc_msgSend hacks.
update SYNC.md — REVERTED to pre-fix state, GUI should work like before
The original code had NO activation policy override. macOS was showing
the Helper window in Ableton's Space by default. Adding Accessory policy
caused macOS to treat it differently and put it in a separate Space.
Going back to the original main.cpp that was working before the close-button fix.
STOP — revert HelperPluginHost to last known working state (GUI in Helper but with original window behavior before all my 'fixes')
I've been making this worse. The original code worked — GUI opened inside
Ableton's window. The problem started when close-button fix changed window
behavior. Need to go back to what worked and make minimal close-button fix only."
fix: show plugin GUI in-process (inside Ableton window) not from Helper
ROOT CAUSE: Moving GUI to Helper process broke it. macOS treats Helper
as separate app → opens in different Space when fullscreen.
SOLUTION: PluginBridge.vst3 (in-process) loads a GUI-only plugin instance.
This instance doesn't process audio — it's only for displaying the editor.
Ableton manages it as a normal plugin window (same as Pro-Q 4 native).
Parameter sync: GUI instance ↔ Helper via IPC (bidirectional).
- User moves knob on GUI → notify Helper → Helper updates real instance
- MCP/automation changes param on Helper → notify Plugin → update GUI instance
Helper no longer shows any GUI window.
fix: set fullscreen-compatible behavior BEFORE making window visible
Previous fix set collection behavior after setVisible(true) which is
too late — macOS has already assigned the window to a Space.
Now sets canJoinAllSpaces + fullScreenAuxiliary + stationary (1<<4)
BEFORE the window becomes visible. Also uses NSPanel-level behavior
and moves window to active Space explicitly via orderWindow:relativeTo:.
If this still fails in fullscreen, the only remaining option is to
render the plugin GUI in-process (framebuffer sharing).
Root cause: NSWindow needs collection behavior flags to appear in
fullscreen Spaces. Without them, macOS puts the window in a separate
Space (different desktop), causing the 'opens in new window' behavior.
Fix adds to showAsFloatingPanel():
- canJoinAllSpaces (1 << 0) — window can appear on any Space
- fullScreenAuxiliary (1 << 8) — window can overlay fullscreen apps
- Window level raised to 25 (NSStatusWindowLevel) which is above
fullscreen app level
This means the plugin GUI will float over Ableton whether Ableton
is windowed OR fullscreen.
update SYNC.md — GUI fix pushed, ready for Claude Code pull+build
The helper was appearing as a separate app in Dock/Cmd+Tab because
the activation policy was never being set. The showAsFloatingPanel()
only handled window level, not the application-level policy.
Now sets policy=1 (Accessory) as the FIRST thing in initialise(),
before any windows are created. This means:
- No Dock icon
- No Cmd+Tab entry
- No focus steal when helper launches
- GUI window floats over Ableton as a panel
Fix GUI focus: Remove makeAccessoryProcess entirely, use NSWindow level trick to float without activation
