VST Audio | VST Instance Controller Component

The VST controller component system lets Blueprint users control plugin-specific parameters without working directly with raw VST parameter IDs. Its a wrapper for the lower level UAxVstInstanceHandle.

At the low level, each live VST instance is still controlled through a generic VST instance handle. That handle exposes functions such as SetParamNormalized, which require a parameter ID and a normalized value. The controller component sits above that handle and gives designers a cleaner Blueprint API.

For example, instead of calling:

				
					SetParamNormalized(123, 0.75f);

a Blueprint (or C++) can call a plugin-specific function such as:

				
					SetMix(0.75f);

The parameter ID remains hardcoded inside the controller component, where it belongs, instead of being repeated throughout gameplay Blueprints.

Typical Setup

Create a Blueprint child class from UAxVstInstanceControllerComponent. Name it after the plugin or effect it controls, for example:

				
					BP_KhsReverbControllerComponent

Inside that Blueprint child, add functions that represent the plugin’s real parameters:

				
					SetMix()
SetRoomSize()
SetDecay()
SetDamping()

Each of those functions should call the protected helper function:

				
					SetParamNormalized() Or 
GetParamNormalized()

and pass the correct hardcoded VST parameter ID for that plugin parameter.

For example:

				
					SetMix(float InNormalizedValue)
    →(Calls) SetParamNormalizedById(MixParamID, InNormalizedValue)

This means gameplay Blueprints only see meaningful parameter names, while the controller component handles the parameter ID mapping internally.

Finding And Identifying Parameter ID: The Vst Parameter Inspector

In the editor, if you open Tools Menu you’ll find the VST Parameter Inspector. This tool helps you identify the ID of the Parameter you may wish to control from Blueprints. Its meant to help you create your blueprint.

Initializing the Controller

The controller component does not automatically search for an audio component. The owning Blueprint must explicitly initialize it with the audio component that is playing the MetaSound containing the VST instance.

A typical BeginPlay setup looks like this: Call InitializeController()

				
					BeginPlay
    → KhsReverbControllerComponent.InitializeController(AudioComponent)

The component uses the provided audio component together with its configured VstInstanceTag to request a runtime VST instance handle.

The VstInstanceTag must match the tag assigned to the VST node inside the MetaSound

For example:

				
					SetMix(float InNormalizedValue)
    →(Calls) SetParamNormalizedById(MixParamID, InNormalizedValue)

This means gameplay Blueprints only see meaningful parameter names, while the controller component handles the parameter ID mapping internally.

Calling Parameter Functions

Once initialized, gameplay Blueprints should use the plugin-specific functions exposed by the controller component:

				
					KhsReverbControllerComponent.SetMix(0.8)
KhsReverbControllerComponent.SetRoomSize(0.5)
KhsReverbControllerComponent.SetDecay(0.65)

All values are normalized, so the expected range is: 0.0 to 1.0.

The controller will clamp values into this range before sending them to the VST instance.

Handling Readiness

A controller can be initialized before the underlying live VST instance is ready. In that case, parameter changes can be queued and applied automatically once the handle becomes ready.

This allows simple setup logic such as:

				
					BeginPlay
    → InitializeController(AudioComponent)
    → SetMix(0.7)
    → SetRoomSize(0.4)

Even if the VST instance is not ready immediately, the latest value for each parameter is stored and applied when the instance becomes available.

Blueprints can also bind to the controller’s OnReady event when they need to run logic only after the VST instance is live.