Added VST SDK support.

docs/PLUGIN_HOSTING.md

@@ -233,9 +233,10 @@ parameters.
 
 Choose the actual binary: `.clap` for CLAP, a VST2 `.so` exporting
 `VSTPluginMain`, or a VST3 bundle's `Contents/<architecture>-linux/<module>.so`
-exporting `ModuleEntry`, `ModuleExit` and `GetPluginFactory`. The chooser does
-not resolve bundle directories or recursively scan plugin folders. On Linux this
-avoids executing unrelated plugins just to discover one selected module.
+exporting `ModuleEntry`, `ModuleExit` and `GetPluginFactory`. The C API also
+accepts conventional `.vst3` bundle paths and resolves the matching architecture
+and bundle-stem binary. The file chooser may require selecting the inner binary;
+no recursive plugin-folder scan is performed.
 Auto-detection prefers CLAP, then VST2, then VST3, otherwise LADSPA; the C API
 also provides `xtc_plugin_probe_format` for an explicit format.
 
@@ -312,3 +313,9 @@ Do not unload/replace modules during playback; candidate plans are prepared off
 the callback and old instances are reclaimed on the control thread. Missing
 references remain inspectable without loading; failed GUI preparation retains
 the current project. Save a backup for applications limited to v11 or earlier.
+
+
+Phase 106 adds [official SDK examples and qualification](STEINBERG.md), including
+VST3 process context (sample position, rate, tempo and musical position), an
+SDK-built gain/synth pair and a WAV render example. Native Windows ASIO remains
+in progress; the optional ASIO SDK example currently provides device diagnostics.

docs/ROADMAP.md

@@ -3363,6 +3363,83 @@ from software-port tests. No dependencies or project-format change were added.
 See [MIDI_WORKFLOWS.md](MIDI_WORKFLOWS.md), [PREFERENCES.md](PREFERENCES.md) and
 [the gallery](../screenshots/README.md) for reproduction and exact limits.
 
+---
+
+## Phase 106 — Steinberg VST SDK and ASIO Integration
+
+### Goal
+
+Use the official Steinberg SDKs to qualify and extend xtc's VST hosting and
+prepare native Windows ASIO audio I/O, with runnable examples. Keep the C99
+engine and public C API; SDK-specific C++ belongs in optional tools/examples or
+an isolated platform bridge. This is a staged phase, **in progress**, not a
+claim that every VST extension or ASIO driver is supported.
+
+### Tasks and acceptance criteria
+
+- [x] Add an opt-in external VST3 SDK CMake build, official validator target,
+      and original SDK-built gain effect and MIDI instrument examples. Ordinary
+      builds must remain offline and SDK-independent.
+- [x] Load conventional Linux VST3 bundles as well as inner binaries, preserving
+      the chosen bundle path in plugin metadata and existing module ownership.
+- [x] Supply VST3 process context with sample position, sample rate, tempo and
+      musical position for effect and instrument processing, including seeks.
+- [x] Provide a headless C example rendering the SDK synth through the gain
+      effect to a no-clobber WAV, and automated SDK/xtc interoperability checks.
+- [ ] Qualify the ASIO SDK device/channel/format/latency diagnostic example on
+      native Windows with a real installed driver. Explicit driver selection;
+      no automatic installation, sample-rate changes or device routing.
+- [ ] Add VST3 edit-controller lifecycle/connection handling, normalized
+      parameters, sample-accurate input automation and parameter feedback to
+      xtc's existing controls and undo paths; test with SDK and real plugins.
+- [ ] Add bounded component/controller opaque-state persistence and transactional
+      reload, with relocation/missing-module and corrupt-state tests.
+- [ ] Extend the graph/host contract for native stereo, multiple buses,
+      sidechains, latency compensation, tails and float64 negotiation; retain
+      explicit rejection until each layout is supported and tested.
+- [ ] Embed native VST3 editors with Linux run-loop/resize ownership, close and
+      reopen tests, and main/audio-thread separation. Extend note expression,
+      MIDI mapping and process-context requirements without inventing timing.
+- [ ] Extend legacy VST2 interoperability (parameters/state/editor/transport)
+      against user-supplied licensed plugins. The discontinued VST2 SDK is not
+      supplied by VST3 and must not be presented as a downloadable dependency.
+- [ ] Introduce a native Windows ASIO backend behind the C backend interface:
+      explicit driver/device selection, buffer negotiation, integer/float sample
+      conversion, double buffers/time-info callbacks, channel mapping, latency,
+      reset/resync/rate-change recovery and callback quiescence. First establish
+      a Windows build of the C engine; do not pretend ASIO is a Linux backend.
+- [ ] Qualify ASIO start/stop/reopen, playback/capture, MIDI coexistence, format
+      conversion and failure cleanup with deterministic driver tests and real
+      Windows hardware loopback; record SDK, OS, driver and hardware versions.
+- [ ] Audit SDK licenses/notices and packaging for each enabled integration;
+      update examples, user documentation and the compatibility matrix after
+      each completed slice. No third-party plugin redistribution implied.
+
+### Implementation status
+
+The first slice adds optional SDK builds/examples, Linux bundle resolution and
+VST3 transport context. See [STEINBERG.md](STEINBERG.md) and
+[examples/steinberg](../examples/steinberg/README.md) for reproduction and exact
+limits. The optional ASIO diagnostic source uses a separately supplied SDK;
+Windows compilation and hardware validation remain pending. The application
+still uses JACK/PipeWire on Linux. Controller/editor/opaque-state, richer bus
+layouts and the native Windows backend remain open acceptance criteria above.
+
+### Validation of the initial slice
+
+On 2026-11-06, `make BUILD_DIR=build/steinberg-host all test` passed with
+warnings enabled. The optional official-SDK target passed Steinberg validator
+**94/94** plus xtc gain/synth, sample-offset and bundle-path save/reload checks
+against SDK revision `3cdf9ca5d1f5b1b21e0a86832aa4abe55607bd96` (3.8.1).
+Focused Clang ASan/UBSan module-path, modern-host and SDK interoperability tests
+passed; static analysis of path resolution and the host facade reported no
+findings. Independent WAV checks confirmed float32/mono/48 kHz, 96000 frames,
+note-off silence and no-clobber destination preservation. Metadata inspection
+accepts readable bundle binaries without executing them. Linux ASIO-option
+configuration correctly rejects the unsupported platform; no Windows build or
+ASIO hardware result is claimed.
+
+
 ---
 
 ## Recommended Execution Order

docs/STEINBERG.md

@@ -0,0 +1,57 @@
+# Steinberg SDK integration (Phase 106)
+
+The VST3 host uses Steinberg's pinned generated C ABI in the C99 core. Optional
+SDK examples now also build against the full, separately supplied official C++
+SDK and run Steinberg's validator. This adds an independent interoperability
+check without adding a C++ runtime or network dependency to libxtc.
+
+## Working integration
+
+- Linux `.vst3` bundles resolve to
+  `Contents/<architecture>-linux/<bundle-stem>.so`. Direct `.so` paths still
+  work. The original chosen path remains the saved identity reference. This
+  supports conventional bundles, not arbitrary renamed modules or Windows DLLs.
+- VST3 processing receives sample rate, absolute sample position, tempo and
+  musical position (`samples / rate * BPM / 60`). Position follows the existing
+  effect/instrument `_at` APIs, including seek. Tempo is the prepared plugin
+  spec's milli-BPM value; reprepare when it changes. Processing is marked playing
+  because this API represents active rendering, including offline rendering.
+  Loop, recording, wall-clock, time signature and continuous-time flags are not
+  asserted: the current plugin API does not carry that information. Positions
+  above `INT64_MAX` reject before processing, matching VST3's signed sample clock.
+- Original SDK-built examples expose a mono half-gain effect and a mono,
+  16-channel sine instrument. The instrument handles note-on/off at their exact
+  block offsets; the host translates all-notes-off to held-note releases.
+- The C render example demonstrates the actual xtc plugin facade and WAV writer,
+  including no-clobber output, without requiring JACK or a GUI.
+
+See [the example instructions](../examples/steinberg/README.md) for SDK versions,
+build commands, validation and ASIO diagnostics.
+
+## ASIO and VST2 scope
+
+ASIO is native driver I/O, separate from VST plugin hosting. The optional Windows
+diagnostic enumerates drivers and inspects an explicitly selected driver's
+channels, sample types, current sample rate, buffer bounds and reported latency.
+It does not create/start audio buffers and is **not an xtc ASIO backend**.
+The current xtc engine/backend still targets Linux/POSIX and JACK/PipeWire.
+Windows portability, a C API platform bridge and native-driver qualification
+are remaining Phase 106 work, not simulated by Linux tests.
+
+VST2 support retains the existing original minimal ABI declarations. VST3's SDK
+does not include the discontinued VST2 SDK. No VST2 SDK or user plugin is copied,
+fetched or licensed by these build targets.
+
+## Remaining work
+
+The application VST3 adapter still accepts one mono input (or no audio input for
+instruments), one mono output, float32 and zero reported latency. Its two mono
+instances are not a native stereo plugin instance. It uses plugin defaults;
+controller parameters, opaque-state persistence and custom editor windows remain
+unimplemented in xtc. The SDK examples include an edit-controller class for
+standard SDK-host compatibility; xtc does not instantiate it yet. The examples
+have no editable parameters or opaque state, so they do not prove those paths.
+No VST extension support or general third-party compatibility is inferred from
+the validator passing these examples.
+
+The complete acceptance checklist is in [Phase 106](ROADMAP.md#phase-106--steinberg-vst-sdk-and-asio-integration).