28 May
2009
28 May
'09
11 p.m.
On Thu, May 28, 2009 at 07:11:55AM -0400, Paul Davis wrote:
On Thu, May 28, 2009 at 6:20 AM, Julien Pommier
<pommier(a)modartt.com> wrote:
i think i have fixed it in FST now. however, this will be much harder in
ardour. good luck :S
its pushed to branch main-thread in the fst git.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Hi,
I have noticed that all JUCE-based vst plugins do not work in fst (at
least their GUI and their internal message passing stuff). The reason
is that the JUCE framework is initialising its internal machinery (a
MessageManager etc) during the first call to the VST entrypoint, and
if the later call to effEditOpen is performed from a different thread,
then all sort of terrible things happens, and it ends with a deadlock.
There is a discussion in the JUCE forum here:
http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?p=21530#21530
Please note that I'm not asking for a fix, but I just want to let the
FST developers know about this problem !
Well, we'd like FST to work with as many different plugins as
possible, so a fix would be nice.
I think Jules actually is making an unreasonable assumption when he
mentions that JUCE is expecting the "initialize" and "open" calls to
come in the same thread. "initialize" is purely about
loading/initalizing the plugin DSP code - its entirely possible to run
a VST plugin without ever opening its editor. The "open" is required
only when the user asks to see the editor. Because of the way win32
event loops work, the thread that is going to wait for events on this
window also needs to be the one that creates it. There is no obvious
reason why this would be the same thread that was used to initialize
the plugin.
There are several other thread "wrappers" such as the Waves shell
which face the same issues as JUCE but work just fine with FST. I'm
entirely open to a fix in FST if there is one that doesn't look like a
grotesque hack :)