It looks like CamelCrusher loads just fine, since the "loading VST plugin" box flashes once before the project stops loading, so I assume that it's the Ozone Imager on the sample that's causing this problem. The sample has two external VSTs on it, CamelCrusher and Ozone Imager. The project starts loading just fine, but when it reacher the "F#Ish Fill" sample, it gets stuck loading a VST and stops loading the project, freezing up, and the only way to close it is to press the exit button a bunch of times. However, I now have another problem that I briefly talked about earlier in this thread, but I'll explain it here in detail. I don't know if this will help or not, but when I re-saved the project as a new one, this problem went away and I was able to load 32-bit plugins into the project just fine. Any thoughts on this? I can add this to #4716. Alternatively, it should suffice to invalidate the plugin upon reception of the IdVstFailedLoadingPlugin message, although I haven't tested this. The nicest solution here would be to backport part of 9db8cbf to stable-1.2.
#Lmms 1.2 rc6 no plugins found code#
The code gets stuck in RemotePlugin::waitForInitDone as the plugin is never invalidated because the 64-bit process exiting is not detected.
However, LMMS currently loads 32-bit VST plugins by launching them as 64-bit, detecting the error loading the DLL, then launching RemoteVstPlugin32.
Loading a 64-bit VST plugin doesn't cause a problem here, because the RemoteVstPlugin process doesn't exit. Once 62 processes are running, Qt is unable to detect when any later-created processes exit.
#Lmms 1.2 rc6 no plugins found windows#
This is the mechanism by which Qt detects when a process exits Windows signals the process handle, the MsgWaitForMultipleObjectsEx call returns, and Qt emits QWinEventNotifier::activated which is connected to a slot in QProcess to perform the process exit behaviour. There is a limit of 62 of these that can exist at any one time, because the event loop implementation on Windows sticks them all in a big call to MsgWaitForMultipleObjectsEx. When a QProcess is started on Windows, it creates a QWinEventNotifier on the process's handle.
This seems to be an internal Qt limitation, although one we can work around.
0 kommentar(er)
