IPB

Welcome Guest ( Log In | Register )

> foobar2000 Development Forum Rules

This forum is for developer discussions only. If you have a problem / bug report / idea / feature request that isn't related to foobar2000 SDK, post it in an appropiate forum instead - tech support questions go to support forum, everything else goes to general forum.
All non-developer posts on this forum will be removed. Continued abuse of this forum will result in admin actions (warnings, account suspension).

 
Reply to this topicStart new topic
UI-bound and session-persistent DSP services?
Yegor
post Nov 20 2011, 20:04
Post #1





Group: Developer
Posts: 253
Joined: 8-April 09
From: Russia, Zlatoust
Member No.: 68779



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
Go to the top of the page
+Quote Post
kode54
post Nov 21 2011, 02:52
Post #2





Group: Admin
Posts: 4664
Joined: 15-December 02
Member No.: 4082



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.
Go to the top of the page
+Quote Post
Yegor
post Nov 21 2011, 07:03
Post #3





Group: Developer
Posts: 253
Joined: 8-April 09
From: Russia, Zlatoust
Member No.: 68779



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.

This post has been edited by Yegor: Nov 21 2011, 07:10
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 27th November 2014 - 11:37