R0-1 — introduce protocol-neutral ProcessBlockView without changing Single behavior

[masarray]

Parent: #56

Blocked by: #57 REG-0 — completed / GO via ADR-0004; #61 UI-0 — completed / GO IMGUI

Purpose

Introduce the protocol-neutral Single processing seam required by Safe VST3 Rack v2 while preserving the existing Single Host protocol and observable behavior.

Fixed-point base for this thread: 060197707a372adce55db63434e7ab709a3d8262.

Vertical proof

The existing Single Host processes the same deterministic audio through the same VST3 engine behavior, but vendor processing no longer fundamentally depends on Single AudioSlot transport.

Mandatory pre-mutation gate

Before changing production Vst3Engine::process(AudioSlot&), add a deterministic real-VST3 engine processing fixture/harness that characterizes the current Single seam, including:

• successful deterministic processing;
• invalid/failure block behavior;
• mono and stereo host blocks;
• mono/stereo plug-in adaptation behavior where feasible;
• block/frame semantics and process-context/sample-position continuity relevant to the seam.

The unchanged Single adapter must pass this characterization first.

Implementation

• introduce bounded non-owning ProcessBlockView or equivalent;
• add protocol-neutral engine process entry;
• keep process(AudioSlot&) as the Single adapter;
• no Single protocol layout/version change;
• no OBS-facing behavior change;
• no UI-0 smoke coupling into Single runtime.

Acceptance

• deterministic audio behavior unchanged across the adapter migration;
• Single protocol layout/version unchanged and tests green;
• lifecycle/state/latency/parameter/process-context regressions green;
• Windows helper/module CI green;
• Compatibility Test Build including supported OBS loader probe green;
• exact candidate receives required representative real-machine Single smoke before merge per ADR-0004.

Non-goals

• no HostedPlugin extraction/rename beyond what is necessary for R0-1;
• no Rack protocol/helper;
• no multi-plugin runtime;
• no Rack OBS filter;
• no production Rack editor/presets;
• no Single protocol redesign.

Thread rule

Stop after R0-1 acceptance/evidence. R0-2 starts in a fresh thread.

[masarray]

R0-1 qualification checkpoint — exact candidate frozen

Exact R0-1 candidate remains:

e09a6b609ca629ae9cd144d1d5a8e9c94f603929

main remains at the fixed-point base 060197707a372adce55db63434e7ab709a3d8262; no concurrent drift has occurred.

Completed evidence

• mandatory pre-mutation real-VST3 characterization PASS on 819e394949184ed64d86901b0cf3e13a3306c6ea, R0-1 Process Seam Characterization Next Level: Crash-proof Single Host + Safe VST3 Rack #8 / run 33135381993;
• final exact-candidate R0-1 Process Seam Characterization Accidental placeholder (closed) #16 / run 33135823346: SUCCESS;
• exact-candidate CI #374 / run 33135823316: SUCCESS;
  • protocol-linux SUCCESS;
  • helper-windows SUCCESS, including 23/23 Windows CTests + scanner smoke;
  • obs-module-windows SUCCESS against current OBS SDK;
  • installer-windows SUCCESS;
• exact-candidate Compatibility Test Build #161 / run 33135823401: SUCCESS;
  • Windows regression tests SUCCESS;
  • scanner smoke SUCCESS;
  • official OBS 29.1.3 loader / ABI-floor probe SUCCESS;
  • package build SUCCESS;
  • production PE dependency inspection SUCCESS;
  • portable package validation SUCCESS;
  • canonical OBS-root installer smoke SUCCESS;
  • artifact upload SUCCESS.

Exact-candidate smoke package

Compatibility #161 artifact:

• artifact ID: 9672227425
• artifact name: OBS-Safe-VST3-Host-v0.4.1-stabilize-test5-windows-x64
• artifact ZIP digest: sha256:c00d99805d25da6ca66e00959d2f70b6cee3a2875e40f07bb8510c94f917c962
• expires: 2026-09-04

The PR merge ref cf7413af9134a866e59b6f7148bc340e0c8f6f14 and candidate head e09a6b609ca629ae9cd144d1d5a8e9c94f603929 both resolve to the identical source tree:

01071c6e7c02ac1e924e19b92351617f68b1f5e6

Therefore the Compatibility #161 package is a valid exact-tree smoke package for this frozen candidate; no rebuild/source mutation is needed.

Artifact contents/checksums:

• OBS-Safe-VST3-Host-v0.4.1-stabilize-test5-Setup-x64.exe — dbad3017d87d5c09c63dd503776080eea6cbacf716fa2a56fa7d9d20c4861cf8
• OBS-Safe-VST3-Host-v0.4.1-stabilize-test5-Windows-x64-Portable.zip — b47d812d0f239a3976405f365c3d98ae2ceb85429d45c42f99b0da59014e0d46

Remaining merge gate

ADR-0004 item 11 / issue #63 still requires representative real-machine Single smoke on this exact candidate tree before merge:

1. normal commercial-VST3 audio processing;
2. helper-owned vendor editor open/hide;
3. exact-state continuity through helper recreation;
4. dry fail-open behavior.

Until that evidence is recorded, PR #65 remains intentionally open, issue #63 remains open, and R0-2 must not start.

Current verdict: BLOCKED only on exact-candidate real-machine smoke; implementation and automated qualification are PASS.

[masarray]

R0-1 real-machine smoke finding — P0 OBS source registration ABI mismatch

Exact previously frozen candidate e09a6b609ca629ae9cd144d1d5a8e9c94f603929 was installed on real OBS Studio 32.1.2 at the correct root. The installed obs-safe-vst3.dll SHA256 matched the exact candidate and OBS loaded that DLL successfully. No duplicate module copy was present.

Real OBS log then showed the decisive failure:

obs_register_source: Tried to register obs_source_info with size 424 which is more than libobs currently supports (408)

followed by:

Source ID 'obs_safe_vst3_filter' not found

Failed to create source 'VST 3.x Plug-in'!

Therefore the Single filter disappearance was a real compatibility failure, not an install-root problem and not an R0-1 DSP/process-seam regression. The existing Compatibility Test Build loader probe was insufficient because it only performed LoadLibrary() + obs_module_ver() and never executed the module's source registration path.

Narrow fix

Commit dc3a52bdb8b6a15026f39c46130b42f0acee5c6a updates only src/obs-plugin/obs_compat_floor.hpp so obs_register_source() is redirected to obs_register_source_s() with the ABI prefix ending at obs_source_info::save, the last source-info field this module populates. libobs zero-initializes its local structure and copies only the supplied prefix, which is the intended compatibility mechanism for append-only source-info growth.

OBS 29.1.3 contains the same filter_audio -> enum_active_sources -> save prefix, so this boundary is inside the repository's declared minimum OBS ABI.

Resolution / repaired exact candidate

Repaired exact candidate:

dc3a52bdb8b6a15026f39c46130b42f0acee5c6a

Git tree:

956e8b3a5720e8242ea2993263521a2bca7d9c51

main remains at fixed base 060197707a372adce55db63434e7ab709a3d8262; no base drift.

Fresh exact-head qualification is now complete:

• R0-1 Process Seam Characterization S2.4 final merge checklist #17 / run 33161584526: SUCCESS;
• CI #375 / run 33161584578: SUCCESS across protocol-linux, helper-windows, obs-module-windows, installer-windows;
• Compatibility Test Build #162 / run 33161584519: SUCCESS;
• artifact ID 9682202575, digest sha256:ee5802f1d18ee61eabb88057973a30830bffb0214c46e03b944e1eb89ddd72e5.

The PR merge ref 95734c03691c2d368e59c714c357d91faedb88aa resolves to the same source tree 956e8b3a5720e8242ea2993263521a2bca7d9c51.

The repaired artifact was installed on the same real OBS Studio 32.1.2 machine and the user confirmed VST 3.x Plug-in is visible again in Add Filter. OBS Single source registration visibility = PASS on the repaired exact candidate.

Remaining gate

This registration recovery is necessary but is not the full ADR-0004 item 11 smoke. Still required on this exact candidate:

1. normal commercial-VST3 audio;
2. helper-owned vendor editor open/hide/reopen;
3. exact-state continuity through helper recreation;
4. dry fail-open behavior.

PR #65 and issue #63 remain open. Do not start R0-2 until those four real-machine observations are recorded and R0-1 is explicitly GO.

[masarray]

R0-1 real-machine smoke checkpoint — helper recovery path PASS, four-point gate still incomplete

Exact repaired candidate: dc3a52bdb8b6a15026f39c46130b42f0acee5c6a.

On the real OBS machine, the Single VST3 filter is present and running ArSonKuPik.vst3. The helper process was observed running as PID 30636, then force-terminated with Stop-Process -Name obs-safe-vst3-host -Force. After 5 seconds a new helper process was present as PID 38376.

The corresponding OBS log records:

• initial helper ready with state=restored;
• native VST3 interface requested via the Open Plug-in Interface button;
• helper exited/unavailable; starting isolated recovery attempt 1;
• recovery completed with isolated VST3 helper ready ... state=restored.

This is direct real-machine evidence that the helper death/restart path is functioning and that the recovered helper accepted restored VST3 state data.

However, fail-closed acceptance still requires explicit representative observations for all ADR-0004 four-point smoke items. The current log alone does not prove:

1. normal commercial-VST3 audio remained correct/processed;
2. vendor editor open/hide/reopen completed successfully (only one open request is present in the captured log);
3. the visible/audible plug-in parameter state after helper recreation exactly matched the pre-kill state;
4. audio stayed dry/non-silent through the helper outage (dry fail-open).

Therefore current verdict remains IN PROGRESS / BLOCKED only on the remaining explicit real-machine observations. PR #65 remains open; do not start R0-2.

[masarray]

R0-1 final real-machine smoke — PASS

Exact candidate: dc3a52bdb8b6a15026f39c46130b42f0acee5c6a
Git tree: 956e8b3a5720e8242ea2993263521a2bca7d9c51
Compatibility #162 artifact ID: 9682202575
Artifact digest: sha256:ee5802f1d18ee61eabb88057973a30830bffb0214c46e03b944e1eb89ddd72e5
Real runtime: OBS Studio 32.1.2 on Windows
Representative VST3: ArSonKuPik

The repaired candidate was installed on the real OBS runtime after the source-registration ABI-floor fix. VST 3.x Plug-in registration visibility returned and the required ADR-0004 representative Single smoke was then completed:

• A Normal commercial-VST3 audio: PASS — processed audio normal.
• B Helper-owned vendor editor open/hide/reopen: PASS.
• C Exact-state continuity through helper recreation: PASS — after forcibly terminating obs-safe-vst3-host, a new helper process appeared and the prior plug-in state returned exactly.
• D Dry fail-open during helper loss/recovery: PASS — OBS remained alive and audio continued dry while the helper recovered.

Runtime log evidence for the recovery path includes:

• helper exited/unavailable; starting isolated recovery attempt 1
• followed by isolated VST3 helper ready: ... ArSonKuPik ... state=restored

All automated exact-head gates are also green:

• R0-1 Process Seam Characterization S2.4 final merge checklist #17 / run 33161584526: SUCCESS
• CI #375 / run 33161584578: SUCCESS
• Compatibility Test Build #162 / run 33161584519: SUCCESS

main is still the fixed-point base 060197707a372adce55db63434e7ab709a3d8262; no base drift occurred. PR #65 merge ref 95734c03691c2d368e59c714c357d91faedb88aa has the same source tree 956e8b3a5720e8242ea2993263521a2bca7d9c51 as the exact candidate.

Pre-merge verdict: GO. PR #65 may now merge. After merge, record the new main SHA, append the parent #56 evidence ledger, close #63, and stop. R0-2 must begin in a fresh engineering thread.

[masarray]

R0-1 merged — GO

PR #65 was squash-merged with expected head dc3a52bdb8b6a15026f39c46130b42f0acee5c6a.

Final merged main SHA: bcddeb78e0b666d8ba2b4ae6d9ce355142181d5d
Final merged tree: 956e8b3a5720e8242ea2993263521a2bca7d9c51

The merged tree is identical to the exact candidate tree that passed:

• R0-1 Process Seam Characterization S2.4 final merge checklist #17 / run 33161584526;
• CI #375 / run 33161584578;
• Compatibility Test Build #162 / run 33161584519;
• representative real-machine OBS 32.1.2 + ArSonKuPik smoke: normal audio PASS, vendor editor open/hide/reopen PASS, exact-state continuity after helper recreation PASS, dry fail-open PASS.

Parent #56 evidence ledger has been updated.

Final verdict: GO.

Per the ticket thread rule, stop here. Next unblocked ticket is R0-2 HostedPlugin extraction, and it must start in a fresh engineering thread.