Any idea why VST3 32 bit builds are not recognized by host (Reaper or FL studio), trying the demos they build successfully however the same problem, must I compile them using a 32bit VM? The host simply does not detect the builds, 64 bits works fine. Anyone successfully builds and imports 32bit version of vst3 for windows?
Thank you,
If the DAW does not recognize 32-bit plugins but 64-bit works fine then it’s probably because the DAW is 64-bit and doesn’t support 32-bit plugins.
Why bother with 32-bit at this point? Where are you trying to use it and why?
It should, both Reaper and FL Studio recognize other 32 bit vsts, not Iplug2 compiled 32 bit though, also using Reaper 32 bit with same problem.
I’m trying to distribute 32 bit version of vsts TIME1 and GATE1 for more reach, not a big deal though.
AFAIK, the only DAWs where 32-bit must be used are legacy DAWs with a small user base. I have an old version of Sony Acid that requires 32-bit VSTs but that is ~25 year old software. I don’t know of any modern-day DAWs that only accept 32-bit VSTs.
I know this doesn’t answer your OP but I wouldn’t spend too much time on it. There might be a library or graphics driver, etc., that compiles but doesn’t work properly in 32-bit hosts, IDK.
Did you try running the debugger when scanning the VST plugins in Reaper (scan from Plugin Manager)?
I think the same, not too worried then, some people still ask for 32 bit vsts but not too concerned, what does it means to run a debugger when scanning vsts? Visual studio debugger? Reaper debugger?
When Reaper hits your plugin it should trigger MSVS and show you what’s happening. You may need to set some breakpoints in the plugin constructor to catch where it goes astray.
Helpful tip, I am not able to scan the 32 bit plugin though no matter the directory I put it on, it does show the scanning load-bar on reaper but after that it does not show on plugins list, thanks for the help, I think I’ll skip 32 bit vst option.
Many times there were cases when a breakpoint was set in the plugin constructor, while the debugger did not stop at it, and a plugin loading error message already appeared in the DAW. And this is exactly for the VST3 version of plugins built on the IPlug2 framework.
I can’t tell you the reason for this behavior. The only way I’ve found to fix this problem is to create a plugin from a known working template.
Many DAWs are now creating cached copies of plugins that they open rather than reading the constructors every time. If they have “seen” that plugin before they open the cached copy. I know Reaper does this and so do Logic and Pro tools. To make sure you are loading the current version of the plugin after making a change always re-scan the plugins in the DAW’s plugin manager - or change the plugin version number.
I have not tried debugging in REAPER, I usually use FL Studio for this purpose, since it loads faster than all DAWs. Breakpoints always work, however, in some VST3 breakpoints set in the first line of the constructor of the main class of the plugin do not work, giving an error window in the DAW. And the problem here is not with caching, since the same plugin, built on the basis of a well-known working template, stops perfectly at the breakpoint in the same position. The problem lies most likely in the VST3 interface.