64-bit VST won't load, 32-bit will (REAPER, OpenMPT)

[GezzMC]

Thanks for the software. I'm in an early phase of trying to use Protoplug as a replacement for JSFX scripting. And if Protoplug works, then it's a huge solution, since Lua is a mainstream programming language that's widely used. Doing music, and learning marketable job skills at the same time, that would be great.

PROBLEM: So in OpenMPT and in REAPER, neither of the 64-bit VST DLLs will load. REAPER fails silently, but OpenMPT returns an error. I'm using Windows 10.

Part of the OpenMPT error message is this: The specified module could not be found.. Maybe that doesn't mean anything special, but does a Microsoft Visual C++ redistributable have to be installed?

QUESTION: So as to script code that's been inserted in the VST editor. This Lua code gets recompiled everytime the DAW starts up and activates the Protoplug VST, right? And there are no external dependencies for the code, such as reading a file to get the code, right? It looks that way. This is big, because REAPER JSFX scripts have to exist as files when the DAW start up.

GREAT UI: From my "Hello, World!" tests, the basics are great. The sliders respond to the scroll wheel, and a double click allow me to enter in an exact value, and there's 127 slider available. Thanks.

[GezzMC]

Fortunately, glasswire.com had installed Microsoft Visual C++ 2015 Redistributable (x86) - 14.0.24212, because when I uninstalled it, 32-bit Protoplug quit working in REAPER. However, REAPER could still see the VST and would load it without the C++ Redistributable being installed; it just wouldn't work. I installed and uninstalled several times.

I play close attention to when something installs a C++ Redistributable, because I've had lots of programs work only because something else had installed the needed C++ Redistributable.

I installed Microsoft Visual C++ 2015 Redistributable (x64) - 14.0.24212, but that didn't make any difference with 64-bit Protoplug. REAPER wouldn't display it in the list of VSTs.

If you're taking requests, it would be nice if the VST are distributed with the necessary C++ Redistributable DLLs. Some applications includes files like msvcp140.dll, but I don't about all that, why some apps do, and some apps don't.

Nothing's obvious about Microsoft Visual C++ 2015 Redistributable. Old versions come up first in searches, and Microsoft download pages never display the version. Somewhere I got 14.0.24212in the past, but the Glasswire today installed 14.0.23026.

[GezzMC]

So the 64-bit LMMS DAW will load the 64-bit Protoplug, and it allows the VST to report it's error, after I install 64-bit Microsoft Visuall C++ Redistributable. I finally found where to get the latest version:

https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

This is the error:

28:33 - Error: Could not load lua51.dll. Tried
E:\(0)\A_1\!muz\bin\!vst\protoplug-1.4.0-win64\ProtoplugFiles\lib\lua51.dll and system path.

The path to the file is correct.

32-bit Protoplug works in LMMS, sort of. The LMMS window that contains the Protoplug window isn't resizable, so I guess it's blocking user inpurt. The Protoplug menu bar items, File, Edit, Build, View, and Help don't do anything.

The bigger problem is that on reload of the LMMS project, the Protoplug window shows the default script code, rather than the last script that was compiled, even though you can hear the effect that was pasted into the window.

Big plans are always derailed because music software is all a big kludge, with massive unknowns. No one's fault in particular.

Thanks.

[GezzMC]

There are no problems, only workarounds. The 32-bit version works good enough, most likely.

[pac-dev]

Thanks for the feedback and problem solving.

I am open to distributing the plugin with the required DLLs, however, it's not necessarily an easy fix. The DLLs normally need to be installed in a system folder, or placed along side the host executable (so users would have to copy msvcp140.dll to their REAPER program folder, for example), which would make the installation process even more complicated. There are options:

• Provide an (optional) installer that ensures all the dependencies are there.
• Have the runtime DLL in ProtoplugFiles and do something sneaky to load it on the fly when the plugin is loaded. That's what I'm already doing with the Lua DLL, but this would be harder, because all of my code apparently already relies on the runtime DLL... So I need a staged loading system. I kind of like the challenge so I'll look into it.