VST instruments don't work in LMMS 1.1.2

[Sti2nd]

Steps to reproduce

• Try to add a VST you know works with LMMS through VeSTige.

It doesn't load, just pops the usual error message "The VST plugin NAME could not be loaded for some reason. If it runs with other VST-software under Linux, please contact a LMMS developer!"

LMMS 64 bit, Windows 8.1

Also reported on the forum
https://lmms.io/forum/viewtopic.php?f=7&t=1664

[Umcaruje]

v1.1.0...v1.1.2

I can't see any commits affecting VST code...

Wierd, or I am missing something...

[tresf]

Did we not have positive test results for 1.1.2 or was that just for effects? Please someone confirm and well revert the download link.

[Sti2nd]

Wierd, or I am missing something...

Nope, it's weird. At first I didn't believe the guy. And I don't remember any VST code either.

[Sti2nd]

Picture sent in message from a user on FB = reported by three so far

[tresf]

Confirmed. It seems there are problems with RemoteVSTPlugin.exe on both 64-bit and 32-bit platforms. Reverting the download link now. Will investigate.

Edit: Upon further investigation, it seems a page fault is causing this which leads me to believe it is build related (such as mingw per ffe7e8b) and not necessarily code related. Here's the output from wine:

wine: Unhandled page fault on read access to 0x9813778f at address 0x9813778f (thread 002d), starting debugger...

And the stack dump from wine:

Unhandled exception: page fault on read access to 0x9813778f in 32-bit code (0x9813778f).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:9813778f ESP:0067fb9c EBP:0067fd10 EFLAGS:00010216(  R- --  I   -A-P- )
 EAX:00000001 EBX:00000000 ECX:00111854 EDX:00000000
 ESI:0067fca0 EDI:001330a8
Stack dump:
0x0067fb9c:  001330ad 0067fca0 00000000 00000000
0x0067fbac:  00000000 00000000 00000000 00000000
0x0067fbbc:  00000000 00000004 0067fcbc 0000006a
0x0067fbcc:  7bca6ff4 00110000 7bca6ff4 00000000
0x0067fbdc:  0045a2cf 0067fcb8 f7559cad 7bca6ff4
0x0067fbec:  43c62300 00134964 00134920 00000028
000c: sel=0067 base=00000000 limit=00000000 16-bit r-x
Backtrace:
=>0 0x9813778f (0x0067fd10)
0x9813778f: addb    %al,0x0(%eax)
Modules:
Module  Address         Debug info  Name (147 modules)
PE    400000-  480000   Deferred        remotevstplugin
PE  10000000-10675000   Deferred        dsk music box

-Tres

[tresf]

I created a build of the lastest stable-1.1 branch which was still configured with the old mingw PPA and it loads a VST just fine suggesting this is related to Toby's latest mingw PPA from January. I've also emailed Toby to let him know.

Below is a screenshot of 1.1.2 built locally for Windows 32-bit. It is running a VST instrument in Wine just fine. This same VST would crash with the Travis-built version downloaded from our site (details listed in the above stack dump).

Assuming Toby can resolve this, we'll bump the version again and release. If not, we can build manually and upload.

[Sti2nd]

Nice find 👍

[musikBear]

i can dl and install -if it make sense? just give me a peep

[tresf]

i can dl and install -if it make sense? just give me a peep

No peep needed. We'll post here when we have an update.

[musikBear]

cute peep 🐰

[tresf]

@tobydox any insight on this one?

[tresf]

@lukas-w we're 5 days without word from Toby on this. Is this something you may be able to help narrow down? Should I just build from scratch against 14.04?

[tobydox]

I did not have a chance to test it but uploaded the latest version of GCC 4.9.x to the PPA.

[tresf]

Thanks @tobydox will try it out.

-Tres

[tresf]

Ok... so I have a build problem. I tried to remove all of the mingw-x packages (because they simply wouldn't update to use the new ppa for me).

I believe they were all removed and re-added successfully, but when building now I get the following:

CPack: - Install project: lmms
CMake Error at /home/tres/lmms/build/cmake_install.cmake:41 (FILE):
  file INSTALL cannot find "/opt/mingw64/lib/libfltk.dll".


CPack Error: Error when generating package: lmms
make: *** [package] Error 1

It seems to be looking in LIB /opt/mingw64/lib/ instead of BIN /opt/mingw64/bin/.

For now, I've copied the DLL over and the build succeeded. Will begin testing shortly.

[tresf]

Testing (win64) seems to fail with the same error...

[tobydox]

FLTK issue is fixed in stable-1.1 and master branch. I'll have a look at the VST issue tomorrow.

[tresf]

FLTK issue is fixed in stable-1.1 and master branch (via 7bd5317). I'll have a look at the VST issue tomorrow.

👍

[tresf]

FYI, this issues is also present on builds made with trusty (Ubuntu 14.04). Just did a clean mingw build environment on 14.04 x64 and same issue, so this is not limited to builds created with precise.

[jobothemojo]

(Windows 32, possibly 64 but not tested)
A quick fix for this issue with vestige would be to rename or delete your Qt4Core.dll in System32 because LMMS creates one to run with RemoteVSTPlugin.exe in the LMMS program file, allowing for two Qt4Core.dll's to be on your pc, and to clash, which causes for RemoteVSTPlugin.exe to not function, the error message saying that it 'couldn't find an entry point' when you open it from the program files as .dll. Another issue with RemoteVSTPlugin.exe is that Avast Antivirus doesn't like it, so make sure that if you have it you go into avast's settings and add the path for RemoteVSTPlugin.exe to avast's list of items not to change or use.

[tresf]

rename or delete your Qt4Core.dll in System32

LMMS installer shouldn't be placing Qt4Core.dll is anyone's System32's. Are you sure you aren't describing a different issue? (i.e. similar symptoms but not related to 1.1.2?)

[jobothemojo]

If you already have Qt4Core.dll in your System32 already (for whatever reason which doesn't concern LMMS) then the one in LMMS program file will cause problems, if you don't already have one then this shouldn't be an issue. I found I had the problem no matter what version I used (I started with 1.0.3 then moved on to 1.1.2, same problems. I then tried 1.1.0 and then figured out what to do. I assume this fix would have applied to the other versions too, but may be a different issue to the one discussed in this forum, just with the same error message) Anyway renaming the System32 one worked for me.

[Sti2nd]

Renaming system32??? Are you joking?

[badosu]

@Sti2nd I think he meant the dll located at system32 folder

[Sti2nd]

Ok. In my System32 folder it is 3200 elements, probably 1000 of them are dll's

[badosu]

If you already have Qt4Core.dll in your System32 already

[tresf]

Ok. In my System32 folder it is 3200 elements, probably 1000 of them are dll's

Yeah, delete them all... 😆 (kidding... please don't!)

[musikBear]

:p i will stop reading that much
Sanity test?

[tresf]

@tobydox the 1.1 patch release is still waiting on the mingw stuff being fixed. :)

[tobydox]

I'm sorry but I don't have solution yet. GCC 4.9 is built like any other previous releases so if they changed something, I don't know what do do. One could start debugging where the exe crashes. Maybe a stack align issue? Try passing "-mstackrealign" to the compiler:

SET_TARGET_PROPERTIES(RemoteVstPlugin .... -mstackrealign)

Maybe replacing -O3 with -O2 also helps?

[tresf]

I haven't tried the suggested recommendations yet... but have some errors through Dependency Walker (probably false positives).

The first that I find interesting is the strange linkings I'm seeing here. Dependency Walker has some known limitations in this regard so it is difficult to figure out if these are legitimate problems or not... namely that VESTIGE.DLL.DLL double extension that is in the list....

I compared it to a working LMMS version and the same linking warnings occurs there...

But Dependency Walker is having a hard time with 1.1.0. It crashes while loading the vesteffect.dll, so I don't really have any basis for comparison when trying to investigate the 1.1.2 crash...

Here's the output of Dependency Walker when trying to load a VST instrument in 1.1.2.

Windows 8 x64:

00:00:05.469: LoadLibraryA("C:/Users/Tres/Desktop\DSK Music Box.dll") returned NULL by thread 1.  Error: %1 is not a valid Win32 application (193).

Detailed log can be found here (gist).

[curlymorphic]

Try passing "-mstackrealign" to the compiler:

SET_TARGET_PROPERTIES(RemoteVstPlugin .... -mstackrealign)

Maybe replacing -O3 with -O2 also helps?

I have tried the above to no avail. I will investigate further when i get time

[curlymorphic]

Ive been looking at this again. I am unable to make any progress.

I was unable to locate the code that produces the dialog box shown in above post.

[tresf]

I was unable to locate the code that produces the dialog box shown in above post.

The Error Reporting doesn't always display. This depends on OS version and the settings of whether or not to create error reports when a problem occurs.

Are you able to reproduce the crash though?

-Tres

[curlymorphic]

Not a crash as such, I do get to this dialog box

then I can return and use lmms as normal, but the vst has not loaded.

im doing this on win 7 in a vm. When i search our code base for the following string or part of, I cant find it. Ive checked the translations files as well

If it runs with other VST-software under Linux, please contact an LMMS-developer!

[badosu]

@curlymorphic You could not find it because it was removed in this commit: 85fb0ac

I don't know why it was removed.

[tresf]

I'm glad it was removed. There's not much reason for that dialog to tell people to contact us when the other error dialogs don't.

I believe the error is derived from here: vestige.cpp#L266.

[tresf]

I think @tobydox was right... This crash is related to the optimization setting... Possibly caused upstream here: gcc/57003, Dupe: winehq/33307, Dupe: redhat/926972

Below is a VST running on 12.04 x64 with:

• GCC optimization set to -O0
• Toby's latest mingw-ppa
• A fresh build from stable-1.1 branch
• all system updates applied.

To be effective, the -03 needs to be changed in both vst_base/CMakeLists.txt#L9 as well as vst_base/Win64/CMakeLists.txt#L8.

[curlymorphic]

@tresf I have tested this using a fresh VM with 14.10 to build on. The Vsts work in both 32/64 bit version, on win 7 in a vm

[tobydox]

FYI: I updated the mingw-x-gcc package yesterday (latest version from Git (4.9 branch)) so the working plugins might be related to it as well.

[tresf]

FYI: I updated the mingw-x-gcc package yesterday (latest version from Git (4.9 branch)) so the working plugins might be related to it as well.

Yes, I saw that however the issue is still present with the latest version.

Only after changing from -O3 to -O0 am I able to get the Win32 VST functionality to work.

I don't know the impact of changing this in our source or even exactly what the cause is, mostly due to my lack of understanding of what gcc versions are affected by this optimization bug versus which gcc version we're using when doing a wingcc compile versus which gcc version were used to make the mingw ppa packages.

So I can switch theCMakeLists to use -O0 and release the 1.1.x patch now, but I really need help understanding the cause as well as the impact of this change moving forward.

-Tres

[eagles051387]

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

it seems like we are reverting to the default behaviour here.

According to the above link this is what -O3 and -OO are

-O3Optimize yet more. -O3 turns on all optimizations specified by -O2 and
also turns on the -finline-functions, -funswitch-loops,
-fpredictive-commoning, -fgcse-after-reload, -ftree-loop-vectorize,
-ftree-loop-distribute-patterns, -ftree-slp-vectorize, -fvect-cost-model,
-ftree-partial-pre and -fipa-cp-clone options.
-O0Reduce compilation time and make debugging produce the expected results.
This is the default.

On Fri, Mar 6, 2015 at 6:05 PM, Tres Finocchiaro notifications@github.com
wrote:

FYI: I updated the mingw-x-gcc package yesterday (latest version from Git
(4.9 branch)) so the working plugins might be related to it as well.

Yes, I saw that however the issue is still present with the latest version.

Only after changing from -O3 to -O0 am I able to get the Win32 VST
functionality to work.

I don't know the impact of changing this in our source or even exactly
what the cause is, mostly due to my lack of understanding of what gcc
versions are affected by this optimization bug versus which ones we're
using when doing a build versus which ones were used to make the mingw ppa
packages.

So I can switch theCMakeLists to use -O0 and release the 1.1.x patch now,
but I really need help understanding the cause as well as the impact of
this change moving forward.

-Tres

—
Reply to this email directly or view it on GitHub
#1757 (comment).

Jonathan Aquilina

[tobydox]

I don't think the problem is caused by the above mentioned bug (described in the bug reports) because it relates to building WINE and not building win32/win64 binary with mingw-gcc. Furthermore the bug is rather old so we would have been affected by mingw-x-gcc 4.8.x as well.

[tresf]

I don't think the problem is caused by the above mentioned bug (described in the bug reports) because it relates to building WINE and not building win32/win64 binary with mingw-gcc. Furthermore the bug is rather old so we would have been affected by mingw-x-gcc 4.8.x as well.

Thanks for clarification.

How do you recommend we proceed? Change to -O0 and move on? File upstream bug w/ mingw team? If we have little to gain with this specific -O3 setting, we can release our 1.1.x patch now. 😕

[tobydox]

Yes O0 is far better than having nothing. Performance might be a bit impacted compared to previous versions but as the actual CPU intensive DSP code happens in the VST plugins itself, it shouldn't be a problem. Does O1 work?

[tresf]

@tobydox,

I believe I tried O1, O2, O3 to no avail. I'll commit the -O0 change to stable-1.1 and fire off the patch release. Thanks for the advice.

-Tres

[tresf]

Closed per d14f451.

Travis should have the 1.1.3 build uploaded to Github here shortly. Once that happens, our downloads page will reflect 1.1.3 as the beta version.

It will show up as a pre-release until we have some testing. @Sti2nd @musikBear if you have time to test this version out with VSTs, that would be terrific. 👍

Once we're ready, we'll flag it as our stable release and I'll manually build and upload an OSX version.

Once that is all out of the way, I'd like to focus our energy on some early beta releases of 1.2.0. 👍

[musikBear]

I have tested
ReleaseVersion 1.1.3 (shows correctly)
*installs
*opens
*preserve settings
*uses locale
*load older project
*replay
*saves
correctly & with no problems on win 32 (xp)

VST-Instrument
loads vst-instrument-container
container loads dll
access to lmms-controllers (wrench)
LMMS controllers works
automation works
automation-connections preserved after save / load

VST-Effects
loads
has effect (vst & ladspa)
can be automated
responds to general-FX (W/D)
automation-connections preserved after save / load

@tresf
Are there any specific test you would like?

Other wise, this looks nice on xp
-In respect to the optimation /permormance impact : I have loaded 2 instances of this relase and both can play simultaneous with no significant cpu spiking -Thats ofcause very impiric and useless, but at least it posible -

(btw Three lmms instances is not! Something creates a conflict, and the computer has serious issues, up til ans including bsod, but that can be my system only)

1.1.3 👍

[tresf]

Terrific, thanks.

I've built and uploaded the Apple version. @Sti2nd , @Umcaruje, want to do the announcement?

[curlymorphic]

@tresf nice for sorting this :)

[Umcaruje]

Made an announcement on the Facebook page. @tresf make 1.1.3 a full release instead of pre-release?

[tresf]

Done. :)

[Sti2nd]

Was just going to as well. Nice