Active Parameters set to null after plugin loads

Topics: Plugin Development, Plugin Parameters, Plugin Persistence, Plugin Programs
Dec 18, 2011 at 6:32 PM


I'm working on adding persistence to my plugin. There is a lot of non parameter info that needs to get saved so I implemented the IVstPluginPersistence interface. My ReadPrograms() and WritePrograms() seem to be working OK. After ReadPrograms() gets called (when I load a file containing my plugin in a host) VstParameterManager_PropertyChanged() gets called for each of my parameters as expected. However then VstParameterManager_PropertyChanged() gets called again for each of my parameters and this time the parameter manager's ActiveParameter is null. Then I get an out of range exception from StdPluginCommandStub.SetProgram() being called. If I ignore this exception and a couple others then my plugin loads fine but the parameters in my plugin aren't linked up to the parameters in the host.


Any idea what could be causing this? Is there something I need to implement besides IVstPluginPersistence?




Dec 19, 2011 at 7:14 AM

It would really help if you could provide the call stack for each of the VstParameterManager_PropertyChanged sequences. That way we can see the origin of the property changes. It is most likely that these property-changed sequences are caused by the program being activated or deactivated.

The out-of-range exception in SetProgram is probably caused by the host calling it with an out-of-range program-index. That in turn could be caused by your plugin not reporting the correct number of programs in its VstPluginInfo. That number is determined very early in the plugin creation process. Is it possible that the number of programs loaded (from chunk) is not the same as the number of programs your plugin has at startup (which ends up in the VstPluginInfo)?

I see that the code in StdPluginCommandStub.SetChunk does not assign the new program count to the VstPluginInfo. That could be a bug.

I specifically didn't implement array bounds checks in the StdPluginCommandStub, so a plugin developer would know when something was wrong. Perhaps I could make those errors more explicit and implement error handling that reports the problem in a more detailed description.

Dec 20, 2011 at 1:15 AM

I was basing my persistence code off of the sample midi note mapper plugin so I totally ignored the VstProgramCollection parameter in Read/WritePrograms(). But now that I'm looking at the persistence code for the sample delay plugin I see how I should be saving the programs. I haven't got it working yet but I think I should be able to figure it out now.

On a related note I don't really understand the concept of loading and saving multiple programs and when you would need to do that. If I wanted to have some default presets would I need to load/save all of them at the same time or could I just load/save the active program? In most VSTis I've used if you edit one program, switch to another program and then switch back then your changes to the first program will be lost. This would lead me to believe that they are loading/saving only the active program every time the user switches the program. Will a call be made to ReadPrograms() every time the user switches programs or only when the plugin is first loaded?



Dec 20, 2011 at 6:20 AM

A plugin that does not remember the changes a user made to its settings is open for some optimization IMHO ;-). The concept of either loading/saving only the current active program or the complete set of programs (also called a bank) is something that is specifically defined in the (native) VST specs. I can think of user scenarios for both. 

The VST.NET Framework keeps all Programs and their Parameters in memory, so changes will always be retained unless the plugin is 'unloaded'. A call to ReadPrograms is a direct result of the host calling SetChunk on the plugin. Usually the Get/SetChunk calls are triggered in the host by user interaction (i.e. menu option).

If you want to make Presets (factory settings that cannot be changed by the user) you have to do some extra work. You have to make sure that calls from the StdPluginCommandStub that change the Program (name, but also SetParameter etc.) will not effect your Preset Program state. 

Notice that I have a todo item for this in the issues list.

Hope it helps.

Dec 22, 2011 at 5:22 AM

Alright thanks for clearing that up. I'm starting to regret using C#'s serialization framework because it means that each program in its deserialized state will have an entire graph of objects associated with it. So deserializing all of my programs may involve initializing a few hundred objects. Not sure if this will end up actually being a performance issue though. Hopefully I'll have some time to find out tomorrow.