UI-bound and session-persistent DSP services?

2011-11-20 19:04:17

I develop a VST adapter which tries hard in providing native experience, which includes DSP chain preset support, following Foobar2000 UI and ability to work in the conversion mode. Although there is some success with this, I'm stuck now due to substantial differences between two APIs.

While VST prescribes its effect instances to be active as long as they're used and to have user interaction handled within those instances, the Foobar2000 DSP API proposes a whole different approach. By contrast, Foobar2000 re-instantiates its DSP services whenever a playback control even occurs, i.e. restart or track change. At the same time it separates the DSP configuration UI from the actual DSP service instances, passing only serialized preset data between the two. This separation makes it challenging to identify which instance of a VST plug-in is to be dealt with.

I worked around some of the difficulties by abusing current Foobar2000 behavior. But it's not a reliable solution to do so and it does fail in certain situations. To reach goals I set, I need some VST-style API in the SDK, i.e. having non-static methods to show config UI and an option to keep the DSP service instantiated as long as possible and/or feasible. I do understand that in general it implies significant changes to the DSP subsystem, but I'm also pretty sure the result is worth it.

Best regards,
Yegor Petrov

UI-bound and session-persistent DSP services?

Reply #1 – 2011-11-21 01:52:52

You could create a flexible foobar2000 DSP configuration data block, one which may or may not contain an identifier which describes which instance of the DSP it is associated with. Couple this with creating and destroying VST instances outside of the thread creating the DSP instances, and you can recycle instances of a given VST effect across multiple instances, stopping only to signal a VST flush without killing the editor.

The unique identifiers would only be emitted by an instance of the DSP being asked for its current configuration, and ignored when assigned to the DSP. They would be used to link a given instance of the DSP to a background created instance of the VST, possibly from a pool of instances of that VST. The DSP instance would use synchronization to unlink itself from the VST pool upon its own destruction.

UI-bound and session-persistent DSP services?

Reply #2 – 2011-11-21 06:03:03

Thanks for your suggestion, kode54, but it's the way it was from the very beginning. Unfortunately, including some sort of ID in a data block doesn't guarantee its uniqueness. You can easily end up with two or more identical blocks when converting a file with the same DSP chain preset as the one used for playback (or simply converting in a multithreaded mode). To work this around I introduced flags which indicate whether particular instance of VST is “busy”, i.e. being used by an instance of a DSP service: if the flag is set then new VST effect is instantiated with the same cfg data. But once again this doesn't solve the problem because when asked for config UI you can't say whether playback or conversion instance is wanted (and you have to handle a special case when two DSP services need to own the same instance of VST simultaneously). There is a dirty workaround for this as well – I check HWND for having “conv” substring in the window title. And this is a kind of a workaround I'd rather avoid.