Wolfgang Kundrus wrote:
I feel like I need to step in here. There are many ways to implement multithreading and there are many ways to prevent resource conflicts. VST plugins are faced with two threads. a) The processing thread that runs at a very high priority and b) The user interface thread that runs at normal priority.
Unless the specs have been updated recently, I couldn't find any clear thread specification or concurrent call descriptions. This means that hosts may call simultaneously any plug-in function from thousands threads. Of course this particular example would be silly, but you get the idea.
If Steinberg has chosen well-defined thread schemes, maybe other VST host developers have chosen others.
We have implemented different multiprocessing schemes with all kinds of VST plugins, including those that use a DSP card. In none of these cases have we run into problems coming from the VST spec as such.
This is not the opinion of non-Steinberg VST plug-in developers testing their products with non-Steinberg VST hosts. Some of them have particular behaviours causing problems which cannot be noticed on other hosts (especially functions setting parameters or programs). It means plug-in developers have to code on the defensive at an extreme point, to be safe. A minimum threading/state specification would have been very welcome. This criticism is not directed only toward VST, but also to other plug-in standards. I hope we'll settle on a good spec/compromise on this topic with GMPI.
==================================+======================== Laurent de Soras | Ohm Force DSP developer & Software designer | Digital Audio Software mailto:laurent@xxxxxxxxxxxx | http://www.ohmforce.com ==================================+========================
---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
