RAM2118 commited on
Commit
496a0a0
·
verified ·
1 Parent(s): 2c0ae05

Sprint 5: ML Intern question — need prepareToPlay verification before implementing

Browse files
Files changed (1) hide show
  1. SYNC.md +28 -6
SYNC.md CHANGED
@@ -18,7 +18,28 @@
18
  > Claude Code will test on Mac and answer before you write anything.
19
 
20
  ```
21
- STATUS: no pending questions
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
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
  ---