VST3

Basic information for plug-in development

VST3 Development

VST3 plug-ins are one of the standard ways to extend modern DAWs with custom audio processors, instruments, MIDI tools, automation bridges, analyzers, controllers, and utility devices.

A VST3 plug-in can be a classic audio effect, a virtual instrument, a MIDI or parameter bridge, or a host-facing control layer that exposes parameters to the DAW automation system.

What this page covers

  • what can be built as a VST3 plug-in
  • how a VST3 bundle is structured
  • where VST3 plug-ins are installed
  • Steinberg VST3 SDK licensing options
  • why VST2 should be treated as legacy

What can be built as VST3

VST3 development can cover many different plug-in types. A plug-in does not always have to process audio directly; it can also expose parameters to the DAW and use those parameters to control external hardware, routing, MIDI messages, or a custom automation layer.

Audio / DSP

  • EQ, compressor, limiter
  • delay, reverb, modulation
  • filters, meters, analyzers
  • experimental DSP processors

Instrument / MIDI

  • virtual instruments
  • synth engines
  • MIDI control utilities
  • parameter mapping tools

Bridge / Utility

  • hardware control bridges
  • DAW automation helpers
  • diagnostic and routing tools
  • controller-facing user interfaces

VST3 plug-in bundle structure

On Windows, a modern VST3 plug-in is normally organized as a bundle-like folder with the .vst3 extension. The real binary module is stored inside the bundle.

Typical Windows x64 structure

MyPlugin.vst3
└── Contents
    ├── Resources
    └── x86_64-win
        └── MyPlugin.vst3

Why this matters

The outer .vst3 item is the plug-in bundle. The inner .vst3 file inside Contents\x86_64-win is the 64-bit binary loaded by the host.

This structure is important when building, installing, packaging, debugging, and code-signing a plug-in.

Default VST3 installation paths

VST3 hosts scan predefined folders. The plug-in does not need a DirectX-style registration step.

Windows user location
%LOCALAPPDATA%\Programs\Common\VST3\

Useful mainly for development and current-user testing.

Windows global location
C:\Program Files\Common Files\VST3\

Common location for 64-bit plug-ins on 64-bit Windows.

Linux locations
$HOME/.vst3/
/usr/lib/vst3/
/usr/local/lib/vst3/

Typical user and global VST3 folders on Linux.

Development workflow

A typical VST3 project moves from source code to a build system, then to a VST3 bundle, DAW scanning, testing, packaging, and release.

C++ source
VST3 SDK
Build system
VST3 bundle
DAW test
Release

For small utilities and hardware bridges, the most important part is often the parameter model. DAWs automate plug-ins through exposed parameters, so stable parameter names, IDs, ranges, and automation behavior are critical.

Steinberg VST3 SDK licensing

The current Steinberg VST SDK is available under the MIT License. For new VST3 development, this is the cleanest licensing path.

Allowed under MIT

  • create open-source VST3 plug-ins
  • create closed-source VST3 plug-ins
  • distribute freeware or shareware
  • sell binary-only VST3 plug-ins
  • modify and adapt the VST SDK source code
  • publish source code on GitHub or a similar platform

Main obligation

The MIT license does not require disclosure of your own source code.

When distributing copies or substantial portions of the SDK code, include the original copyright notice and the MIT license text.

Open-source, closed-source, and third-party frameworks

Open-source VST3

A project may publish its source code, include or reference the VST SDK, and still distribute binary builds of the plug-in. This is suitable for educational plug-ins, experimental DSP tools, community projects, and free utilities.

Closed-source / commercial

A developer may distribute only the compiled binary without publishing the full plug-in source code. This fits paid plug-ins, private tools, hardware bridge utilities, internal studio tools, freeware, and shareware.

Third-party frameworks

VST3 plug-ins can also be developed with frameworks such as JUCE. In that case, follow both the VST3 SDK license and the license of the selected framework and dependencies.

VST2 legacy warning

VST2 is a legacy format and should not be used for new public development unless the developer already has the required old Steinberg VST2 license agreement.

For new developers, VST3 is the correct target. A VST2 plug-in or host may only be distributed if the developer signed the VST2 license agreement before October 2018. Without that older agreement, distribution of VST2-based products is not allowed.

Practical recommendation

  • Use VST3 for new plug-in releases.
  • Use the current MIT-licensed Steinberg VST SDK.
  • Keep the required license notices.
  • Use stable versioning and a predictable parameter model.
  • Package the VST3 bundle correctly.
  • Provide SHA256 checksums for public downloads.
  • Code-sign public Windows binaries when possible.
  • Avoid VST2 for new public distribution.

Example use case: hardware bridge plug-in

A VST3 plug-in can act as a bridge between a DAW and external hardware. Instead of processing audio directly, the plug-in exposes automatable VST3 parameters to the DAW. When those parameters change, the plug-in can translate them into MIDI CC, Program Change, SysEx, OSC, or other control messages.

DAW sees a normal plug-in
User sees automatable parameters
Hardware receives control messages

Official references

This page summarizes basic VST3 development and licensing information. For authoritative details, always check the official Steinberg VST3 Developer Portal.

Was this information useful to you?

Help me improve this website content with a simple vote.

0
0

Komentáře jsou uzavřeny.