I had to do a quickie updated to ASPiK to fix a bug with the VST3 sidechaining code that Dave Clark found. This pushes the revision to 1.6.9 and only the vst3plugin.cpp file changed - all else was the same. I also rolled in another fix a GitHub users committed and pushed via Git, that dealt with soft bypass. This new update has only one file that is changed for VST3.
I also tweaked the pluginbase.cpp file to add a protection mechanism for processing audio blocks or buffers, that would only occur if a partially filled block (or partial buffer) arrived. This would have no affect if you process in frames, which most do.
Hey Will, sorry to be a pain but I'm having some issues with builds with on this and the 1.6.8 update.
Basically the PluginTemplate and ASPiKreated release builds fail to load into VSTHost (extremely unusual) instantly throwing an assertion error at line 185 of vstguidebug.h in the VSTGUI library.
In Reaper I can load the VST but can then easily set it up to throw a critical error resulting in an unhandled exception at vstgui/lib/platform/win32/win32support.cpp, which looks like this;
HINSTANCE GetInstance ()
if (auto wf = getPlatformFactory ().asWin32Factory ()) /// <== unhandled exception
return wf->getInstance ();
Getting the Debug build going in Reaper and entering the WYSIWYG editor, it throws an assertion error and crashes on attempting to save over the PluginGUI.uidesc now complaining about line 243 of vstgui/uidescription/rapidson/include/rapidjson/prettywriter.h
As all these issues seem to be stemming from the latest VSTGUI updates so perhaps I should attempt to take this up on the Steinberg forum.
I think the problem may ultimately be related to an extreme reluctance on my end to upgrade from Windows 7. Using Visual Studio 2017.
I just did a test with ASPiK 1.6.9, the current release.
First, I used the ASPiKreator to create two VST3 projects, one processing frames, the other blocks. I used VS2019 to build them.
I ran the Debugger with the latest version of Reaper 6.33 (which has a bug with VST3 bundles, and I had to copy my .vst3 manually out of the bundle) and I never got any kind of exception thrown. I am on Win10.
I did get an error (warning) in the output window about JSON -- the newest VSTGUI uses JSON as well as XML for the .uidesc file. JSON is tried first, and if that does not work, it reverts to XML parsing (there is a compiler setting that the Steinberg CMake modules produce that sets this "USE XML" flag). The message looked like this:
JSON Parsing Error: Invalid value.
At byte offset: 0
I loaded and unloaded the plugins in Reaper, and had no exceptions or other issues - they worked as expected.
Next, I did a test by copying the PluginTemplate, changing the name of the folder (just for my sanity) and editing the CMakeLists.txt file to generate the plugin project outside of ASPiKreator, and I did find one bug - there is a bit of missing CMake script in the CMakeLists.txt file in the template. Note that the ASPiKreator does not edit this CMakeLists.txt file - it uses its own version. After fixing that, I generated and tested the VST3 plugin without an issue. No exceptions thrown.
I have wasted so many hours of my life over the years with the VSTTestHost, thinking my plugins were at fault, and they were not (bugs in the test host), so I do not trust or use that anymore. I usually use Reaper as my goto test host, especially since the MacOS version also loads AU plugins.
Now, I do need to rev ASPiK to fix that PluginTemplate outer CMakeLists.txt file, but if you had edited it, the plugin would have not compiled anyway. And, so far no one has reported this because it is so much easier to use the ASPiKreator which does not produce the bug.
One major change they made in VSTGUI4.10 was that they added a function call to initialize the library, which involves the global variable hInstance you noted. You can find my call in the PluginGUI.cpp file at line 141:
The hInstance global variable is declared a few lines above this (and that is all part of VSTGUI4, nothing to do with ASPiK).
You can find the initialization of this in the dllmain.cpp file (under the Source Files folder in VS), where they store the instance handle:
BOOL WINAPI DllMain (HINSTANCE hInst, DWORD dwReason, LPVOID /*lpvReserved*/)
if (dwReason == DLL_PROCESS_ATTACH)
#if defined(_MSC_VER) && defined(DEVELOPMENT)
_CrtSetReportMode (_CRT_WARN, _CRTDBG_MODE_DEBUG);
_CrtSetReportMode (_CRT_ERROR, _CRTDBG_MODE_DEBUG);
_CrtSetReportMode (_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
int flag = _CrtSetDbgFlag (_CRTDBG_REPORT_FLAG);
_CrtSetDbgFlag (flag | _CRTDBG_LEAK_CHECK_DF);
moduleHandle = ghInst = hInst; // <-- there it is
Note that is a VST file, not an ASPiK file. You can then find where it is attached to hInstance in the PluginGUI.cpp file:
#ifndef AAXPLUGIN // VST or RAFX Win
hInstance = moduleHandle;
For AAX plugins, this is done inside of the AAXPluginGUI.cpp file.
For AU, this is moot because MacOS does not use HINSTANCE.
So, out of this I have found that I need to rev the outer CMakeLists.txt file in the PluginTemplate folder. But I never got an exception thrown. I do not have a Win7 machine anymore so can not test it there, but instance handles have been around as long as Windows itself.
OK Will thanks for checking.
The way I was crashing Reaper was by loading a few plug instances across a track and the master, saving the session, then reloading the session. Only upon reloading the session Reaper would crash.
Stepping through the debugger with the plug loaded in Reaper I can see that it will step through the VSTGUI::init((HINSTANCE)hInstance); line without issue, so that was probably a red herring.
Stepping next through the next few lines though;
description = nullptr;
throws the JSON parsing error that you also saw. Maybe non-critical but stepping out from PluginGui() triggers a memory error somewhere else and I get this output;
**std::_Unique_ptr_base<VSTGUI::UIDescription::Impl,std::default_delete<VSTGUI::UIDescription::Impl> >::_Myptr**(...) returned 0x20.
which is a read access violation thrown from deep in VS 2017/community/Tools/MSVC/../memory.h
To see what would happen, I tried commenting out the if (!description->parse()) condition and when I reloaded the plug into Reaper it instacrashed and I received the same Assertion error that VSTHost gave from vstguidebug.h
Maybe this suggests along with the prettywriter.h issue of not being able to save to the uidesc from the editor, that the problem lies with the plug attempting/failing at parsing the PluginGUI.uidesc correctly?
By the way I was throwing the vstguidebug.h error in VSTHost by Hermann Seib rather than the VSTTestHost. It's a rock solid DAW that I use for live performing. Lacks a transport and track editing but is extremely lightweight even compared with Reaper and has much better MIDI functionality. Hermann also puts out SaviHost which is a neat single VST loading DAW that will wrap a VST into a standalone executable file.
But if you can't reproduce those issues don't fret. I'll eventually get a new OS going which I still think could resolve this.
OK - thanks for the added details regarding multiple instances.
I think you have found something that requires my attention, and it has to do with the new initialization stuff that was added to VSTGUI4.10.
I definitely have an issue here - it only happens with multiple instances and is involving that global variable I discussed in the previous post. The memory error you found I think may be a result of heap corruption and probably a side effect.
I will need to get this fixed and updated in ASPiK/RackAFX ASAP. Wish I didn't have a real job taking all my time right now : ) but it is a really fun job.
I will post here when I have the fix in place.
Most Users Ever Online: 152
Currently Browsing this Page:
Guest Posters: 1
Moderators: W Pirkle: 640