Can't deal with instantiation in another VST adapter

2010-10-31 08:13:28

I managed to load a VST DLL and succesfully enabled it in the fb2k dsp chain. But that's only in the limits of the derivative of dsp_impl_base. As you know, fb2k doesn't keep dsp classes instantiated all the time, and configuration is called within a static method with dsp_preset parameter provided (and callback to affect instantiated DSPs). In contrast VST makes use of a completely different aproach: an instance of an effect class is kept in memory all the time and both processing and configuration are always performed within the instance.

Now the problem is that I can't find a way to keep VST instances running while my DSP implementation class is re-instantiated all the time or isn't instantiated at all. In other words, I don't know how to keep instances of my dsp class linked to their VST instances and how to refer to VSTs I'm keeping running to call configuration window. Some kind of map like “dsp_preset → VST instance” comes to mind, but in this case I don't know how to keep track of removed dsp plugin instances.

Please don't suggest trivial static solutions as the adapter is planned to support multiple instances. The code is here but it's only two days old and so it doesn't look polished, it's just a testing area

Thanks a lot.

Can't deal with instantiation in another VST adapter

Reply #1 – 2010-10-31 23:26:30

It might help if you look at dsp.cpp in the SDK foo_sample project. It demonstrates how to store instance-specific configuration as members of your DSP class, as well as how to assemble those variables into a DSP preset, process a DSP preset to configure your DSP instance, and also how to assemble a WTL dialog to edit your DSP presets.

You could very well design your DSP preset to include such information as the path to the VST effect and/or its unique identifier word, and the entire configuration block for the VST instance. Then you could design a simple WTL dialog container for the VST's own editor window, and OK/Cancel buttons. (The configuration window could be for a separate instance of the VST, or could be for the instance that the editor is being called on, so the user can apply changes in semi-realtime.)

Can't deal with instantiation in another VST adapter

Reply #2 – 2010-11-01 03:58:25

It should be the same instance for both cfg window and dsp itself (ok/cancel are to be made by tracking parameter changes). The problem is about keeping this same vst instance as long as it's actual, i.e. editor window open and/or dsp is working and/or it's in the active DSPs list. I found that there is dsp_config_callback which notifies about changes in the main dsp chain. But there are two major problems: dsp_config_callback only works for the main chain and dsp_config_manager can't be asked to give core settings from DSPs constructor (it appears that as long as constructors own control the dsp_config_manager is in undefined state; I would use it to track what chain a dsp_preset belongs to).

So it seems I can't deal with requirment of keeping vst instance as long as it's in the main chain. If only there was some method to determine by what chain a dsp_preset is used, I could do what I need. By now, I wasted all workarounds I could made. So I'm going to turn this requirment down and try to solve the problem with reference counting.