Vst2 Wrapper VST 3.6.7 crashes hosts on Windows

Developer VST 3 SDK
#1

Hello!
There is a problem.

I build sample project “again” and use vst2 wrapper.
I change file extension from again.vst3 to again.dll.
I open one copy this plugin in hosts (I used FL Studio, REAPER) and it works, but if I open second copy again.dll in next insert FX slot, host is crashed.

Is it a bug or something I’m doing wrong?

Thanks.

#2

This is happening for me as well - just tried it. Adding the second instance as VST crashes the host. It does not halt when running in the debugger, though, just crashes the host. I tried with Reaper and Cubase 7 and both crash when you add the second instance. Also tried Reaper 32 and Reaper 64 with same result.

Some notes:

  • The VST3 version does not crash the host, only the VST-wrapped version.

  • The vst wrapper function create( ) does succeed (both times) and returns an AudioEffect*

  • The GUI does show up for the second instance, but the host locks / freezes right after it is shown

  • The crash only happens for Windows clients; Reaper on MacOS did not have issues

  • Will

#3

I can also confirm this issue in Max 7 under Windows 10, with VST2 plugins created using the vst2wrapper supplied in the 3.6.7 SDK.

Has anyone found the cause of (or solution to) this problem? Does anyone know if this issue has been fixed in the 3.6.8 SDK?

#4

My Windows VST2 wrapped plugins are working properly and with multiple instances with the 3.6.8 SDK. I tested with Reaper and Live 9 (I only tested 64-bit builds).

  • Will
#5

Great, thank you for the confirmation.

#6

I can confirm that this also happens on OS X for SDK 3.6.8.

When I load a wrapped 2.4 plugin into Ableton Live it works great until I add a second instance. Like others mentioned, as soon as you open the second instance, the GUI isn’t visible and the entire application freezes up. I have noted this with builds that are either 64-bit only or for both 32-bit and 64-bit architectures (i386 and x86_64).

Is this on Steinbergs radar ? Anything obvious we are missing apart from following the Again build example?

#7

I managed to resolve my issue.

I discovered my plugin was sharing memory space in its process function (said plugin is an instrument that synthesizes audio into its given output buffers). By moving from namespace scoped variables into a class based processor this issue was resolved (long story short: buffers were overflowing between instances wreaking havoc). While this was somewhat tolerable as a VST3 in Bitwig (though very loud), as a VST2.4 this would instacrash while the problem was apparent all along. Guess it pays off to make sure your code is actually working, cough.

Hope this is of help to the others who posted here.