I think C/++ is just prone to these errors. It's all Bjarne Stroustrup's fault..
When loading a preset for my plugin in Cubase 5, I get stuck in loadVST2CompatibleState at
jassert ('VstW' == htonl (*(juce::int32*) data));
The same code runs fine in Cubase 7 (but I only have a LE license for that...).
I have to admit I have no idea what you're checking for there, but I'd be glad to give further information once I know what to look for...
P.S.: when I comment out that line, everything seems to run fine ( but I'd rather keep my JUCE uchanged...).
Just tested on Cubase 5.1 on Windows 7 and it seems to work fine here -
- created and saved a session using the VST2 (when VST3 is removed from plugins folder)
- opened the session using the VST3 (when this time the VST2 is removed from the plugins folder and the VST3 is in place) and all worked fine
Can you give some more info about the problem - like
- what versions of Cubase and OS are you using?
- how do you trigger the bug?
- what value is there instead of the one the assert is expecting? (in
"(*(juce::int32*) data)" )
Also works on Cubase 5.0.1 on OS X 10.8.4
Sorry, hit the wrong reply button, meant to post over there: http://www.juce.com/forum/topic/vst3-plugin-wrapper?page=8#comment-304130
After playing around with it some more, I'm not sure if commenting out that line is all it takes to solve the problem.
Using OSX 10.9.2, Cubase 5.5.3 now (but ended up at the same assert when I was testing Windows 7 & Cubase 5.5.3 (32-bit) yesterday).
What I do is:
1. open a new empty project, create a new track and load the VST3 version of my plugin
2. change some parameters and store a preset
3. remove the plugin from the channel
4. add the VST3 version of the plugin again
5. load the preset from 2.
I'm not too familiar with the Xcode debugging options, but when I add this line before the assert...
const juce::int32 test1 = (*(juce::int32*) data); jassert ('VstW' == htonl (*(juce::int32*) data));
... test1 is 34156188 while data is "\x9c.\t\x02".
(My AudioProcessor::getStateInformation does nothing special (just a few parameters stored via XML) and used to work fine before (still does when using Cubase 7 LE.)
Ok, this (crash when loading presets in VST3 in Cubase 5) reproduces here too.. Thanks for catching this!
In the debugger I notice two things:
- "size" is 1! Looks like readFromMemoryStream simply doesn't work right in Cubase 5
- When using just readFromUnknownStream instead of readFromMemoryStream we do get actual data
- However, when reading a VST3 preset file - a ".vstpreset" file rather than a ".fxp", in Cubase 5 we get the whole content of this file including its header (which starts with "VST3").
So for now I'll try the following fix - use just readFromUnknownStream and not readFromMemoryStream, and in "loadVST2CompatibleState" - check if the data starts with 'VST3' or big-endian 'VstW' and support skipping the vst3 .vstpreset file's header..
Made a fix for this (VST3 wrapper now also supports loading .vstpreset files as its data because that's what Cubase 5 gives it when loading them) -
Ended up not disabling readFromMemoryStream as I suggested before because it contains some Adobe Audition CS6 workaround which I don't want to remove, but instead loadStateData returns whether it was successful or not.
Mart, can you try this patch and see if it solves the problem at your end as well?
Yes, that seems to solve my problem (didn't test in depth but the preset loading procedure I described above now works). Thanks!
Thanks guys - I'll take a look at the patch ASAP!
I recently noticed unexpected behaviour when setting plugin parameters via Cubase's Texteditor-Style value input field (see attached picture). I had to enter the normalized [0.0 , 1.0] values there to set the parameters right.
So I found what I'd need to implement would be Steinberg's IEditController::getParamValueByString method.
Steinberg provides a default implementation in EditController::getParamValueByString where the string is just parsed to double. Cubase then uses that value to set the plugin's parameter. (Hence, the behaviour described above).
So here is a proposal how to add that method to JUCE (adding a default implementation to juce::AudioProcessor that behaves just like Steinberg's default implementation):
Works fine when properly overriden (did not test on Windows yet).
Something that I recently noticed and that I can reproduce with the DemoPlugin:
Using: OSX 10.9.2, XCode 5.1.1, Cubase 5.5.3
Building: VST3 Universal Binary 32/64 Bit, Base SDK 10.7
Steps to reproduce the crash:
1. open a new empty project, create a new track and load the VST3 version of the plugin
2. change a parameter
3. unload the plugin without storing anything (confirm to discard changes)
-> Crash with EXC_BAD_ACCESS somewhere in a libobjc.A.dylib's disassembly (see attached screenshot for details)
I couldn't reproduce this using Cubase 7 LE and I have to admit the combination of Cubase 5 and OSX 10.9 is rather obscure (and not offcially supported by Steinberg)...
I tried with Cubase 5.0.1 on OSX 10.9.3 and OS X 10.8.4 and this problem reproduces on both.
I found that one has to keep the plugin window open at step 3 for the crash to happen.
With Cubase 7 it works fine - will now also check on Windows but I have a hunch it will work fine there as the crashes are in libobjc..
Works fine in Windows 7 (problem does not reproduce)
It seems to crash in [NSAutoReleasePool drain]
Xcode for some reason can't figure out the whole stack trace on its on, so..
It seems to be calling the "release" method for something
I found two problems with the VST3 wrapper in Wavelab and also found solutions for them:
Wavelab often crashes when quitting
It seems to call process with null buffers before closing..
Fix/work-around at https://github.com/yairchu/JUCE/commit/55a3c3e6d5b619614fa3b40479f23aff7abc187e
Fails to load presets
It reports kResultFalse as return code of IBStream::read but actually does read the data successfuly and updates number of bytes read..
Fix/work-around at https://github.com/yairchu/JUCE/commit/0f1b318ef16cdcc9b4fec1fc5f48c6105211636a
I hope no more issues pop up (and there's still the Cubase 5 issue that Mart found..)
Latest changes in my "wavelab" branch should also fix an issue with VST3 support for midi-only plugins - though I haven't tested those as I don't have any to test..
Sorry to dig this thread out of its oblivion…
With Cubase LE AI Elements 8 (v8.0.10), when hammering the A/B button on a VST3 plug-in compiled with the tip of the develop branch (e.g. JuceDemoPlugin/VST3), I end up with a crash inside loadVST2CompatibleState with
size = 10 and
data = "" according to the debugger:
(or other sizes like the following one on one occurrence with JuceDemoPlugin/VST3 :
Anybody with a vague idea?
VST3 A/B Crash