VST3Go

vst3go is the low-level Go interface and runtime layer for VST3.

This fork is intentionally different from the original justyntemme/vst3go project. It is being kept deliberately narrow as a clean VST3 binding/runtime layer, while the higher-level DSP and synth-oriented functionality lives in the companion synthkit repository.

It contains:

• VST3 C API headers and C bridge glue
• Go bindings for VST3 types and process structures
• The plugin wrapper/runtime used to expose Go processors as VST3 plugins
• Generic plugin authoring primitives such as buses, parameters, process context, state, and MIDI/event transport

The higher-level audio and synth layer now lives in the companion synthkit repository.

For the web-rendered plugin editor flow, see docs/web-editor-bridge.md. For Windows build and packaging notes, see docs/windows-build.md. For the real Windows validation handoff checklist, see docs/windows-validation.md. For a condensed Windows quickstart, see docs/windows-validation-quickstart.md. For a ready-to-fill Windows validation run record, see docs/windows-validation-report-template.md. For lifecycle, thread-safety, and persistence expectations, see docs/runtime-contracts.md. For day-to-day implementation and validation conventions, see docs/development-workflow.md. For a very detailed downstream plugin-building guide, see docs/developing-with-vst3go.md. For commercial login/licensing integration guidance, see docs/commercial-authentication.md. For pre-tag signoff, see docs/release-checklist.md. For publishing notes, see docs/release-notes-template.md.

Scope

vst3go keeps the VST3-facing pieces:

• bridge/
• include/vst3/
• pkg/vst3/
• pkg/plugin/
• pkg/midi/
• pkg/framework/bus
• pkg/framework/param
• pkg/framework/plugin
• pkg/framework/process
• pkg/framework/state

The companion synthkit repo owns:

• pkg/dsp/
• pkg/framework/dsp
• pkg/framework/debug
• pkg/framework/voice
• examples/

Public API Boundary

• Downstream code should treat pkg/plugin, pkg/vst3, pkg/midi, and the retained pkg/framework/* packages as the supported API surface.
• bridge/ and the editor assets exist to support that API surface, but product-specific DSP and showcase logic stay out of this repo.
• If a feature needs higher-level audio product behavior, it belongs in synthkit or the consumer project instead of this runtime layer.

Consumption

• Downstream repos should import github.com/cwbudde/vst3go and build on the supported package surface rather than reaching into bridge internals.
• Once versions are tagged, consumers should pin a tag instead of a moving branch so bridge/runtime changes can be upgraded intentionally.
• DAW validation, signing, installers, and product-specific DSP behavior remain downstream responsibilities.

Companion Repo

Recommended name: synthkit

Purpose:

• DSP building blocks
• instrument/effect showcase plugins
• higher-level audio helpers built on top of vst3go

Development

Core checks in this repo:

just fmt
just fmt-check
just test

Validation

• This repo validates the shared runtime layer with just test and the Windows build path with just windows-smoke when the host shell is available.
• Platform-specific integration checks, host app behavior, and downstream DSP/plugin wiring belong in the companion synthkit repository or the consumer project.
• Windows packaging and bundle layout checks in this repo stay focused on the generated DLL, header sidecar, and layout contract.
• Real Windows signoff should follow docs/windows-validation.md so toolchain, bundle, host, and WebView2 behavior are captured consistently.

Release Scope

• This repo ships the VST3 binding/runtime layer, the web-rendered editor shell, and the Windows bundle/build harness that supports that shell.
• This repo does not ship the higher-level DSP, showcase, or product-specific synth logic; those remain in synthkit.
• Release validation for this repo is centered on just test, just windows-smoke, and the documented bundle/layout checks.
• Final pre-tag review should follow docs/release-checklist.md.

Windows-specific editor and packaging notes:

• bridge/windows_dll.c provides the DLL entry point.
• bridge/bridge.c exports GetPluginFactory for the Windows build.
• pkg/plugin/cbridge/windows_dll_windows.go makes the DLL entry source part of the Windows cgo build.
• pkg/plugin/editor_view_windows.c expects WebView2 headers and loader support.
• Windows support currently targets amd64 and the x86_64-win bundle layout.
• just windows-preflight auto-selects a compatible Windows compiler when needed and checks for windows.h, WebView2.h, and WebView2Loader. If no compiler works, it reports the candidates it tried and why each one failed.
• just windows-smoke runs a local script-only smoke test that exercises selection, preflight, build, packaging, and bundle validation without a real Windows host.
• just windows-init-report creates a prefilled Windows validation report scaffold with current host metadata.
• just windows-validate runs the end-to-end validation sequence on a real Windows machine and writes a report file.
• just windows-build-dll builds the Windows shared library when the Windows toolchain is available.
• just windows-build <dll> assembles a VST3 bundle directory from a built Windows DLL and requires the generated header sidecar.
• just windows-check-bundle validates the resulting bundle layout.
• just windows-release runs preflight once, then build and validation in one go.
• docs/windows-build.md describes the expected bundle shape.

License

This project is licensed under the MIT License. The bundled VST3 SDK headers remain under their respective licenses.