This project has moved and is read-only. For the latest updates, please go here.

Hooking up parameters to a custom UI

Topics: Editor UI, Getting Started, Plugin Parameters
Apr 18, 2011 at 3:19 AM


I am trying to hook up a VST parameter to a control on the GUI using the example provided in the source code. I've got it working so that when you change a parameter in the host it moves a knob in my UI but I can't seem to get it working the other way around. When I move a knob on my UI it calls this function:


        private void lbKnob_KnobChangeValue(object sender, LBSoft.IndustrialCtrls.Knobs.LBKnobEventArgs e) {
            var knob = (LBKnob)sender;
            var paramMgr = (VstParameterManager)knob.Tag;

            paramMgr.ActiveParameter.Value = knob.Value;


I can verify that the function is successfully setting the value of the parameter but that value in not reflected in the host. e.g. the parameters sliders in the host don't move. Do you have any idea what could be causing this?




Apr 18, 2011 at 11:39 AM

If you use the latest release binaries you should call the IVstHostCommands10.SetParameterAutomated method after you've changed the parameters value. You can get to this a reference of the IVstHostCommands10 interface by overriding the GetPluginInfo method on the PluginCommandStub object of your plugin. (its not a virtual but I think you can implement a 'new' one on your object. Pass the IVstHostCommands10 reference to your plugin root object and then to the PluginEditor object and then to your Form.

If you use the latest source code to build VST.NET yourself, get the latest version and use the new VstParameterManager constructor that also takes a reference to the IVstHostAutomation interface and it will call the NotifyParameterValueChanged method for you.

My guess is that this will fix your problem.

Hope it helps.

Apr 18, 2011 at 5:41 PM

Thanks for the info. I have build the latest source code but I can't figure out how to get an instance of IVstHostAutomation to pass to the VstParameterManager constructor. I noticed that you can get it from VstHostInterfaceManager::GetInstance() but I don't know how to get at VstHostInterfaceManager either. Do I need to implement my own version of IVstHostAutomation?




Apr 18, 2011 at 5:52 PM
Edited Apr 18, 2011 at 5:54 PM

Close, but no cigar! ;-)

var hostAutomation = _plugin.Host.GetInstance<IVstHostAutomation>();

See for an example.

All IVstHostXxxx interfaces can be acquired this way. You never need to implement the IVstHostXxxx interfaces. The interfaces represent communication a plugin can perform with its host.

Apr 18, 2011 at 9:12 PM

Glad to hear that I don't need to implement all of the VstHost interfaces :) I still haven't got it working though because _plugin.Host is still null the first time CreateMidiProcessor() is called. The second time CreateMidiProcessor() is called _plugin.Host is no longer null but the MidiProcessor has already been created so the parameters are not reinitialized. Any idea what I'm doing wrong?

Apr 19, 2011 at 6:41 AM

Hmmm, I see where the problem lies (didn't think of that ;-). It looks like you are not doing anything wrong.
The problem is, is that the Framework tries to query your plugin for its capabilities (implemented interfaces) at a time when the Open (that passes in the host command stub) call has not yet been received on the plugin root object (IVstPlugin).

So for now, its probably best to remove the initialization from the constructors and do a lazy initialization. You could override the Open method on the IVstPlugin root object and call initialize(parameters) on all objects that need it.

I will see if I can make an interface and a standard implementation for this. Thanx for the catch! ;-)

Apr 19, 2011 at 10:13 AM

My current thought is to implement an Opened event on the Plugin base class(es). This way all plugin sub components can subscribe to it as needed.

How does that sound?

Apr 19, 2011 at 4:13 PM

I tried your suggestion of initializing the parameter managers in the Open() method but the problem with that is that the ActiveParameter never gets initialized. So if I try to use data binding to bind the ActiveParameter's value to something I get an error. And even if I don't do any data binding the host doesn't recognize that there are any parameters.

This also made me wonder what would happen if you use data binding to bind a GUI control to a ParameterManager's ActiveParameter and then the user loaded a new program. Would the knob still be bound to the old (not active) parameter?

Apr 19, 2011 at 7:05 PM

Ah yes. The plugin info that is published to the host, is created very early in the process and if you don't publish the parameters the host doesn't know you have them.

If you get the latest code and build it you have the option to handle the Opened event on the plugin root base class(es). At that point you can assign the host automation interface reference to the VstParameterManager instances. Initialize the parameters in the ctors as before.

Check out the VS project templates (Support) for an example.

I haven't tested this fully, but I feel confident it will solve the initialization sequence issue.

Please let me know how you're doing.


Apr 19, 2011 at 7:07 PM

Oh, your second question: The binding should also get a property changed notification on the ActiveParameter property, indicating it should release the old instance and bind to the new.

Apr 19, 2011 at 7:27 PM

It worked like a charm. Thanks a lot for all the help!

Apr 20, 2011 at 8:15 AM


Thanx and also thanks to you. You have helped to make VST.NET a little better ;-)