Sprint 5: ML Intern question — need prepareToPlay verification before implementing
Browse files
SYNC.md
CHANGED
|
@@ -18,7 +18,28 @@
|
|
| 18 |
> Claude Code will test on Mac and answer before you write anything.
|
| 19 |
|
| 20 |
```
|
| 21 |
-
STATUS:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 22 |
```
|
| 23 |
|
| 24 |
---
|
|
@@ -87,20 +108,21 @@ missing from CMakeLists.txt — added. All working now.
|
|
| 87 |
## NEXT PUSH — ML Intern fills before every push
|
| 88 |
|
| 89 |
```
|
| 90 |
-
STATUS: waiting
|
| 91 |
|
| 92 |
-
TASK:
|
| 93 |
FILES CHANGING:
|
| 94 |
-
-
|
| 95 |
FILES NOT TOUCHING (confirm locked files are safe):
|
| 96 |
- PluginBridgeEditor.mm ✅ not touching
|
| 97 |
- PluginPickerComponent.mm ✅ not touching
|
| 98 |
- HelperPluginHost.mm ✅ not touching
|
| 99 |
- HelperConnection.cpp ✅ not touching
|
| 100 |
NEW FILES (Claude Code must add to CMakeLists.txt):
|
| 101 |
-
-
|
| 102 |
APIS USED (verified by Claude Code? y/n):
|
| 103 |
-
-
|
|
|
|
| 104 |
```
|
| 105 |
|
| 106 |
---
|
|
|
|
| 18 |
> Claude Code will test on Mac and answer before you write anything.
|
| 19 |
|
| 20 |
```
|
| 21 |
+
STATUS: QUESTION PENDING
|
| 22 |
+
|
| 23 |
+
QUESTION: Sprint 5 requires routing audio through inProcessPlugin->processBlock().
|
| 24 |
+
But loadInProcessPlugin() intentionally skips prepareToPlay() with this comment:
|
| 25 |
+
|
| 26 |
+
"We do NOT call prepareToPlay() — the in-process plugin is GUI-only and never
|
| 27 |
+
processes audio. Calling prepareToPlay() causes some plugins (iZotope Neutron,
|
| 28 |
+
inter-plugin comms plugins) to spin up internal audio threads that then race
|
| 29 |
+
with unloadInProcessPlugin() and crash the audio thread."
|
| 30 |
+
|
| 31 |
+
If I now route audio through inProcessPlugin, it NEEDS prepareToPlay() to be called.
|
| 32 |
+
|
| 33 |
+
OPTIONS:
|
| 34 |
+
A) Add prepareToPlay() to loadInProcessPlugin() — risk: iZotope/Neutron crash
|
| 35 |
+
B) Call prepareToPlay() only for SAFE plugins that will get audio routed — same risk?
|
| 36 |
+
C) Keep the current architecture (Helper does audio, in-process is GUI-only) and
|
| 37 |
+
instead sync the Helper's internal state to the in-process GUI instance so the
|
| 38 |
+
spectrum analyzer updates. Would need Helper to send FFT data via IPC.
|
| 39 |
+
D) Something else?
|
| 40 |
+
|
| 41 |
+
Which approach is safest? Can you test: load Pro-Q 4 in-process with prepareToPlay()
|
| 42 |
+
called — does it work or crash? The iZotope concern may not apply to FabFilter.
|
| 43 |
```
|
| 44 |
|
| 45 |
---
|
|
|
|
| 108 |
## NEXT PUSH — ML Intern fills before every push
|
| 109 |
|
| 110 |
```
|
| 111 |
+
STATUS: BLOCKED — waiting for Claude Code answer on prepareToPlay question
|
| 112 |
|
| 113 |
+
TASK: Sprint 5 — route audio through in-process plugin
|
| 114 |
FILES CHANGING:
|
| 115 |
+
- PluginBridgeProcessor.cpp (processBlock + loadInProcessPlugin)
|
| 116 |
FILES NOT TOUCHING (confirm locked files are safe):
|
| 117 |
- PluginBridgeEditor.mm ✅ not touching
|
| 118 |
- PluginPickerComponent.mm ✅ not touching
|
| 119 |
- HelperPluginHost.mm ✅ not touching
|
| 120 |
- HelperConnection.cpp ✅ not touching
|
| 121 |
NEW FILES (Claude Code must add to CMakeLists.txt):
|
| 122 |
+
- none
|
| 123 |
APIS USED (verified by Claude Code? y/n):
|
| 124 |
+
- inProcessPlugin->processBlock() — y (inherits from AudioProcessor)
|
| 125 |
+
- inProcessPlugin->prepareToPlay() — NEEDS VERIFICATION (safe for Pro-Q 4?)
|
| 126 |
```
|
| 127 |
|
| 128 |
---
|