I'm using a Windows 10 Laptop, 64 bit.
One of my LMMS projects will load external 64-bit plugins and native plugins just fine, however when I try to load any external 32-bit plugin into LMMS, be it an effect or a synthesizer, LMMS will say it's loading the plugin, but then freezes up and won't let me click anything.
If I click exit and then minimize LMMS on my laptop, it'll make the box with the option to save your project pop up, and I can exit out of the project that way, but the "Loading plugin" box to the bottom left of the screen stays unless I click on it and let Windows tell me that it's not working, shutting it down that way.
Is there an explanation to this? I've been able to use 32-bit and 64-bit plugins in every other LMMS project except this one, and at one point in the past I've been able to use 32-bit plugins inside this project. I don't remember exactly when the project stopped loading 32-bit plugins.
Thanks! :)
You say this happens with one of your projects. I'm assuming that means it doesn't happen when you start a new project. Can you provide the project you're referring to?
@EtornaZ Does this include every x32 VST?
-Have you tried to load one you previously have had success with, if it fails, then
Restart your pc
Then try to load that plugin in a brand new project
What is that result?
@musikBear Yes, I have tried to add 32-bit VSTs that worked in the project in the past, and they've failed. I don't see the point of loading a 32-bit plugin into the project and restarting my computer if I can load any 32-bit plugin I have into any other LMMS project.
@SecondFlight Yes, you're correct. I can load 32-bit plugins into any other project in LMMS except this one.
Here is the project.
https://drive.google.com/file/d/1LOrgOb0CJkDnPJGfepvKJSCCDYyVHlNU/view?usp=sharing
Here's the list of VSTs used in the sample project.
Auburn Sounds Couture-64.dll
CamelCrusher.dll
DragonflyReverb-vst.dll
FerricTDS.dll
GClip.dll
MSW2.dll
MeldaProduction\Distortion\MWaveFolder.dll
MeldaProduction\Tools\MRatio.dll
OTT_x64.dll
Ozone Imager.dll
Paradox.dll
SlamDawg_x86.dll
TAL-Reverb-2-64.dll
TDR Nova.dll
TDR VOS SlickEQ.dll
reaxcomp-standalone.dll
I can load 32-bit plugins into any other project in LMMS except this one.
So in fact, this is a flawed project, not a general x32-VST bug.
@musikBear Yup.
^^ I don't think we can conclude this at all.
@EtornaZ Was this project originally begun in a version earlier than rc7?
Yes. I believe it was rc6, but I still couldn't load 32-bit plugins into it. The project actually got to the point where sometimes it would get stuck in the process of loading (in rc6), but when I started using rc7 the project opened for me.
Yes. I believe it was rc6, but I still couldn't load 32-bit plugins into it.
If you like, PM me the project, and i will look at it @EtornaZ
https://drive.google.com/file/d/1LOrgOb0CJkDnPJGfepvKJSCCDYyVHlNU/view?usp=sharing Here's the link to it @musikBear
@EtornaZ tnx, i will see if i can find anything weird
@EtornaZ As you can see
i had no problem loading x32 plugins in your project at all. I tried Synth1, and MDApiano -kind of my proof-of-concept VSTs. But i am not sure it really matters that i can load any VST. I had a whole page of 'not-founds', and it could be any of those, that mess up your project. In fact -that is most likely the problem.
Before i start dissecting code, i would like you to try to load MDApiano. You find the link here:
MDA-Piano http://mda.smartelectronix.com/synths.htm
Does that fail?
It does fail, yes.
@EtornaZ
It does fail, yes.
woooo... 8|
that is ..odd! You did wait a bit for it to load..? Even though MDAp it actually load like a bolt
..Hmm
o..k -I would like to know the Number of :
Automation-tracks in song-editor
Instrumental- tracks in BB-editor
Count them and post the numbers!
I will try to do a convert on your mmpz, if it fails i let you know, because then i need a mmp-file from you.
Here's the project with all the VSTs removed: Weird Bounce House_novst.zip
If you open this up, can you load 32-bit VSTs into it?
@DomClark Yup, I sure can. Maybe I just have to reload all of the 32-bit plugins into the track again and it'll fix the problem, but I'm not trying that until I absolutely have to.
@musikBear
16 instrumental tracks in song-editor
30 automation tracks in song-editor
15 instrumental tracks in B&B editor
1 automation track in B&B editor
@EtornaZ Fine! Now i can compare and check if tracks are all there
@EtornaZ I cant find anything, that can explain why you cant use x32 VST. The file looks ok. It must be one of the used plugin, that prevents normal usage.
You could assist us all, by identifying this plugin, you would need to make a dummy project, and in sequence
When the Test step fail, the plugin you added just before last save, is a candidate for being the reason for the fail.
Then the candidate need to be singular tested
...You can also pack all the dll in one zip, upload it, and give us/me the address for the package here, then i can do the testing :p
@musikBear Thank you for looking into this! I will try what you've said later and let you know if any of the plugins currently in the project are prohibiting me from loading 32-bit plugins.
Here are versions of the project containing a single type of VST each: Weird Bounce House Single VSTs.zip
Can you load 32-bit VSTs into all of these?
Never mind, cause found.
I noticed something similar, since I use LMMS actually (beta 0.4, back in 2014) :
When the project counts 62 VST (I know that's a lot, but still, sometimes on huge projects that happens)
And to quote @EtornaZ
If I click exit and then minimize LMMS on my laptop, it'll make the box with the option to save your project pop up, and I can exit out of the project that way, but the "Loading plugin" box to the bottom left of the screen stays unless I click on it and let Windows tell me that it's not working, shutting it down that way.
So, @DomClark, @SecondFlight do you think I should open a new issue for that or could it be related ?
Thanks in advance.
EDIT : I checked the sample project @EtornaZ provides above and... there are 62VST's ! So I think it's definetly related !
When the project counts 62 VST (I know that's a lot, but still, sometimes on huge projects that happens)
- If I load a 64bits VST, everything will be fine
- If I laod a 32bits VST, the VST will try to load, endlessly.
Reproduced. How weird. I'll investigate, thanks for the information.
OK, here's what's going on:
This seems to be an internal Qt limitation, although one we can work around. When a QProcess is started on Windows, it creates a QWinEventNotifier on the process's handle. 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. 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. Once 62 processes are running, Qt is unable to detect when any later-created processes exit.
Loading a 64-bit VST plugin doesn't cause a problem here, because the RemoteVstPlugin process doesn't exit. However, LMMS currently loads 32-bit VST plugins by launching them as 64-bit, detecting the error loading the DLL, then launching RemoteVstPlugin32. The code gets stuck in RemotePlugin::waitForInitDone as the plugin is never invalidated because the 64-bit process exiting is not detected.
The nicest solution here would be to backport part of 9db8cbfb31f9b6d3e754887a6280770e3d3e2bcd to stable-1.2. Alternatively, it should suffice to invalidate the plugin upon reception of the IdVstFailedLoadingPlugin message, although I haven't tested this. Any thoughts on this? I can add this to #4716.
Once 62 processes are running, Qt is unable to detect when any later-created processes exit.
That is absolutely amazing finds! :+
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.
...However, I now have another problem that I briefly talked about earlier in this thread, but I'll explain it here in detail.
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.
The sample has two external VSTs on it, CamelCrusher and Ozone Imager. 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. Is there a way to delete that existence of Ozone Imager from the project without opening the project?
Here's the new project with this problem. https://drive.google.com/file/d/1QbeLWDWsWM7tg6bDU7imwiQu82VOAFDB/view?usp=sharing
Sorry if this is a little off-topic, please move this comment over to a new thread if any of you feel like that's necessary.
Not quite sure how it fixed itself, but the Ozone Imager on the sample is the 63rd VST to be loaded in the project, and is 32-bit so will break things. Here's a file with it removed, although removing any other VST should also fix it so just ask if there's another one that would be better to remove.
Weird Bounce House (without load glitch).zip
Note that adding another 32-bit VST here will probably break things again; hopefully we can fix this for the next release.
If you want project files fixed up without filling up GitHub issues, you can always ask in #support on Discord.
Alternative fix:
We could move the QProcess to the ProcessWatcher thread, and run an event loop there instead of the current test-sleep loop. The actual restriction is 62 QWinEventNotifiers per thread, so this would avoid any resource exhaustion at all, rather than just working around it. This has the advantage that the process watcher will continue to function beyond 62 processes, and may (very slightly) improve CPU usage as the watcher thread need only wake when the process exits or when told to, rather than every 200ms to check up on the process.
FYI, the Qt bug(QTBUG-8819) is fixed in Qt 5.10(https://github.com/qt/qtbase/commit/5c6210e3452f78cab2f58887e747eb5cb2501f70 and https://github.com/qt/qtbase/commit/85403d0af06a0728c9c6f1bd7a6f224949cd894e).
Fix added to #4716.
Most helpful comment
FYI, the Qt bug(QTBUG-8819) is fixed in Qt 5.10(https://github.com/qt/qtbase/commit/5c6210e3452f78cab2f58887e747eb5cb2501f70 and https://github.com/qt/qtbase/commit/85403d0af06a0728c9c6f1bd7a6f224949cd894e).