Parameter changes from custom editor

Topics: Plugin Development, Plugin Parameters, Plugin Persistence, Plugin Programs, VST.NET Framework
Mar 26, 2011 at 2:40 PM

Hi Marc,
first of all, thanks for the brilliant framework - excellent work indeed!
I am trying to set up an audio effect with a custom editor (using Cakewalk Sonar Home Studio as a host). Everything works fine except for automation / parameter persistence.
Within the change handler of my parameter controls, I tried VstParameterManager.ChangeValue(x) as well as VstParameterManager.ActiveParameter.Value = x, but no automation data are written, and the updated value is not saved on host termination.
When using the built-in default host editor instead, everything works as far as UI-generated parameter changes are concerned. Changing the parameter from within a timer elapsed handler does not work either.
Only if I switch programs back and forth, the changed value will become persistant.
Do you have any hint for me what to try or where to look for a solution?
Best regards,

Mar 26, 2011 at 2:46 PM

Hi Lutz,

First of all VstParameterManager.ChangeValue only changes the value on the manager object itself, not the parameter. The correct call is the VstParameterManager.ActiveParameter.Value property. Indirectly that should also trigger the ChangeValue method (through changed event on the VstParameter itself).

The VstParameterManager does not automatically call the IVstHostAutomation.EditParameter and SetParameterAutomated. Oops I see that SetParameterAutomated is not exposed in the Framework (IVstHostAutomation). You can use the VstHostCommandStub on the Host property to access it - you receive the host in IVstPlugin.Open. Meanwhile I will add it ;-)

I think that if you call these methods it will work as expected. BUT (disclaimer) I haven't tested this myself (painfully obvisously ;-). 
BTW: Are you sure you set the CanBeAutomated property on each VstParameterInfo?

Give it a try and let me know if it works.
Hope it helps,

Mar 26, 2011 at 2:48 PM

Hi Marc,
thanks a lot for the instantaneous response - I will give your proposal a try as soon as possible.
Yes, I set CanBeAutomated to 'true'; I guess that's why automation and persistence works fine when using the host's default editor.
I have no objections against using the forum - I just did not dare to as I am totally new to the subject. Do you have means to publish this thread belatedly? Please do so, if you like; in that case I would post my results (or further questions) there.
Thanks again

Mar 26, 2011 at 2:52 PM

Persistance will probably work automatically by the host. You can also implement custom persistence, but if you only have standard programs/parameters you shouldn't have to.

I've checked in the changes. Get the latest source if you want to try it out.

(I think we have now documented our emails ;-)


Mar 26, 2011 at 3:03 PM

(BTW - I am not new to programming, I am just new to VST and to using forums... :) )

In the meantime I managed to access the IVstHostAutomation and IVstHostCommandStub instances by calls to IVstHost.GetInstance<T>().

I called EditParameter() and SetParameterAutomated() passing '0' as parameterIndex (there is only one parameter up to now), and - voila - automation and persistance work perfectly now from the custom user interface - great!

What happens, if more than one parameter are involved? Would I index the parameters in the order they have been created? Or can I retrieve a parameter's index somehow from VstParameterManager.ActiveParameter?


Mar 26, 2011 at 4:10 PM

Indexing in the order in which the parameters have been added to the VstProgram's .Parameters collection works fine.

For full integration (Plugin parameter change, host automation, host persistence) a custom editor parameter control (knob, slider etc.) should initiate the following calls from within its ValueChanged handler:

  • ParameterManager.ActiveParameter.Value = <value>;
  • IVstHostAutomation.EditParameter(<parameter index within VstProgram.Parameters>);
  • IVstHostAutomation (or IVstHostCommandStub in previous framework versions) .SetParameterAutomated(<index>, <value>);


Mar 26, 2011 at 4:29 PM
Edited Mar 26, 2011 at 4:31 PM

- the ValueChanged event handler of the UI control, I presume...

Dont forget to call Dispose on the return value of EditParameter. The EditParameter call is meant (from what I understand) to be called from the UI: call EditParameter on mouse down and Dispose on the return value on mouse up. Any drag movement the user makes with the mouse (while the button is down) that causes parameter value changes should be called in with SetParameterAutomated. Not sure if the host will call your "SetParameter" (VstParameter.Value) in response to the call to SetParameterAutomated, though...

I designed the VstParameter to get rid of the whole parameter-by-index stuff (used by the native VST interface) . But I never got the host calls to integrate. Perhaps this is a good time to see if we can smooth it a bit...? Perhaps just adding an Index property on the VstParameter object would allow you to pass in VstParameter references to the EditParameter and SetParameterAutomated calls...?

Mar 26, 2011 at 5:39 PM

With my host (Cakewalk Sonar Home Studio), EditParameter returns a null object, so I cannot call Dispose().
If skip the call to EditParameter() (or BeginEdit()/EndEdit()), automation and persistence are still fully functional.
The behaviour may be different with other hosts??

For the Sonar host, I can confirm, that SetParameterAutomated does not trigger any PropertyChanged event on the corresponding ParameterManager;
setting ParameterManager.ActiveParameter.Value is obviously required.

As the UI control event handler needs the ActiveParameter anyway, it would of course be nice if it could be passed to SetParameterAutomated with the VstParameter instance "knowing" its index and its updated value; the new signatures would then be SetParameterAutomated(VstParameter parameter) and EditParameter(VstParameter parameter)??

Mar 26, 2011 at 6:33 PM

If EditParameter returns null, it means the host does not support it. Indeed for other hosts it might return a non-null value. So I would check and call Dispose if return value is non-null.

Your suggestions is exactly what I was thinking about. ;-)

I will get to work on it ;-)

Mar 26, 2011 at 8:49 PM

I've checked in the changes. Please check it out and let me know if this works for you.

VstParameter now has an Index property. It is a calculated property value (IndexOf on the collection) in order to simplify maintenance when inserting parameters.

EditParameter has been renamed to BeginEditParameter and SetParameterAutomated has been renamed to NotifyParameterValueChange and both take a VstParameter instance. For NotifyParameterValueChanged the idea is that you set the new value on the VstParameter and supply that to the method to notify the host.

Mar 27, 2011 at 1:22 PM

Sounds great!

Unfortunately I am neither set up for VS2008 nor for Subversion - so I currently cannot participate/contribute on source code / source control level.

BTW: I opened and "issue" that may be relevant for a lot of users depending on which Types their plugin assembly contains: ManagedPluginFactory.LocateTypeByInterface may cause an exeption, if the Type.FullName property is <null>, which - strange enough - may happen.

Mar 27, 2011 at 7:37 PM

You can just download the sources in a zip. VS2008 is another matter. if you use VS2010 it will upgrade for you (but you will run on .NET 4.0) if it is VS2005 you have to rebuild the project files...

Thanx for submitting the issue. Its through feedback like this that everybody benifits and the stability of VST.NET increases. Thanx!

Mar 27, 2011 at 7:52 PM

Just updated the source. Drop me an email at obiwanjacobi at hotmail dot com and I'll send you the compiled dlls in a zip. ;-)