(tested with the AudioDemoPlugin and latest reaper on mac intel)
With JUCE_VST3_CAN_REPLACE_VST2 defined (1), if you save a project with a vst2 and reload it with the vst3, the plugin state isn’t loaded correctly and those 2 assertions are triggered:
jassert (htonl ((uint32) bank->version) == 1 || htonl ((uint32) bank->version) == 2);
jassert (JucePlugin_VSTUniqueID == htonl ((uint32) bank->fxID));
Does anyone got JUCE_VST3_CAN_REPLACE_VST2 to work in reaper?
I have faced a problem related to JUCE_VST3_CAN_REPLACE_VST2 recently, I wonder if it may be related. What version of JUCE are you using?
In modules/juce_audio_plugin_client/detail/juce_PluginUtilities.h
try commenting out the part shown below, that’s enabled when JUCE_VST3_CAN_REPLACE_VST2 is set:
#if JucePlugin_Build_VST
static bool handleManufacturerSpecificVST2Opcode ([[maybe_unused]] int32 index,
[[maybe_unused]] pointer_sized_int value,
[[maybe_unused]] void* ptr,
float)
{
// #if JUCE_VST3_CAN_REPLACE_VST2
// if ((index == (int32) ByteOrder::bigEndianInt ("stCA") || index == (int32) ByteOrder::bigEndianInt ("stCa"))
// && value == (int32) ByteOrder::bigEndianInt ("FUID") && ptr != nullptr)
// {
// uint8 fuid[16];
// getUUIDForVST2ID (false, fuid);
// ::memcpy (ptr, fuid, 16);
// return true;
// }
// #endif
return false;
}
#endif
This is the part where the VST2 actively declares that it wants to be replaced with a VST3 and for us it was causing some unintended VST2->VST3 replacements and missed loads on Studio One projects
EDIT: this has nothing to do with the feature in the VST3 wrapper where it should declare that it can replace a VST2 with a corresponding ID if it is missing
This is the part where the VST2 actively declares that it wants to be replaced with a VST3
interesting, thanks.
but that won’t solve the issue. Note that I want the vst2 to be replaced by the vst3.
I uninstall the vst2 intentionally so that reaper replace it with the vst3.
(Basically I want all the sessions that were using the vst2 to correctly load even if only the vst3 is installed).
gentle bump.
Is there any chance to get JUCE_VST3_CAN_REPLACE_VST2 to work in reaper ?
Could you elaborate more on the problem? I’m fairly confident I’ve seen VST3’s replace VST2 plugins in Reaper using JUCE in the past? can you maybe try with one of the example plugins?
Hi Anthony.
I tested with the AudioDemoPlugin and the latest reaper on mac intel.
The issue is that <ith JUCE_VST3_CAN_REPLACE_VST2 defined (1), if you save a project with a vst2 and reload it with the vst3, the plugin state isn’t loaded correctly and those 2 assertions are triggered:
jassert (htonl ((uint32) bank->version) == 1 || htonl ((uint32) bank->version) == 2);
jassert (JucePlugin_VSTUniqueID == htonl ((uint32) bank->fxID));
To reproduce:
Sorry I missed that, I’ll try and take a look.
While you are digging around in this code, can you remove the JUCE_VST3_CAN_REPLACE_VST2 test from this:
void loadStateData (const void* data, int size)
{
#if JUCE_VST3_CAN_REPLACE_VST2
if (loadVST2CompatibleState ((const char*) data, size))
return;
#endif
setStateInformation (data, size);
}
Or else you can’t load VST2 state if you implement VST3ClientExtensions::getCompatibleClasses in your VST3 plugin.
@lalala sorry this has taken a while. I can reproduce the issue you’re seeing and I think I’ve finally got a grip on at least some parts of what’s going on, what I’m currently seeing is.
The version of the bank comes out as 0, the docs say this should be 1 or 2, this isn’t a big problem we can ignore this
The fxID is wrong. I can’t determine exactly why or how this is happening yet, but as far as I can tell we can ignore this without issue
Reaper is ignoring 128 bytes in the middle of the fxBank struct leading to data and the size of the data being determined by out-of-bounds data! The relevant section in the VST3 SDK looks like this
#if VST_2_4_EXTENSIONS
VstInt32 currentProgram; ///< version 2: current program number
char future[124]; ///< reserved, should be zero
#else
char future[128]; ///< reserved, should be zero
#endif
from that I’m concluding that reaper must have their own struct they are using which isn’t matching this one.
What I’m still yet to do is
If we release a fix for this and then Reaper also releases a fix it’s likely our fix will need another tweak, in other words it will break again. Alternatively if Reaper release a fix and we didn’t do anything then all existing plugins would just start working so I think we’ll have to consider if this is the best course of action.
I’ll keep you posted.
@RolandMR I’ll try to take a look at this. Without giving it a huge amount of thought just yet my main concern would be if this results in a breaking change.
Here is how I modified it in my juce branch:
bool vst3CanReplaveVst2()
{
#if JUCE_VST3_CAN_REPLACE_VST2
return true;
#else
if (auto ext = pluginInstance->getVST3ClientExtensions())
return ext->getCompatibleClasses().size() > 0;
return false;
#endif
}
void loadStateData (const void* data, int size)
{
if (vst3CanReplaveVst2())
if (loadVST2CompatibleState ((const char*) data, size))
return;
setStateInformation (data, size);
}
@lalala sorry for the wait on this, this should now be resolved on develop. It turns out Reaper was using a version 0 of the fxBank which as far as I can tell is undocumented anywhere. Regardless newer versions of the VST3 SDK can handle loading and saving VST2 states so we’ve managed to drop any reliance on needing the VST2 SDK in this case too.
@RolandMR I’ve added some changes to support your request too. We needed to drop reliance on the requirement for the VST2 SDK to implement it because otherwise everybody would have to have the VST2SDK just incase they implemented getCompatibleClasses()!
Let me know if it works for you.
Hi Anthony,
Thank you for looking into this.
Unfortunately your commit seems like a major breaking change, as previously saved sessions with JUCE_VST3_CAN_REPLACE_VST2 aren’t loading anymore.
Here is what I tried:
with the latest juce7 version, open the AudioPluginDemo project, define JUCE_VST3_CAN_REPLACE_VST2 to 1 and build both the vst2 and vst3.
create a Reaper project with both the vst2 and vst3 in it. save and close.
delete the vst2 and vst3 binaries.
with the latest juce8 version, open the AudioPluginDemo project, define JUCE_VST3_CAN_REPLACE_VST2 to 1 and build both the vst2 and vst3.
open the previously saved Reaper project
result-> vst2 loads fine. vst3 does not load
close the reaper project
delete the vst2 binary
reopen the reaper project (to try to load both vst2 and vst3 states with the new vst3)
result-> vst2 does not load. vst3 does not load
Let me know if you can’t reproduce or need more info.
@lalala thanks for reporting I’ll take a look at this first thing this morning. I’m guessing because I’m leaning on the SDK for the state saving/loading it’s caused a backwards compatibility issue. I had originally implemented the fix without resorting to that but to support the other request in this topic I had to drop the VST2 SDK requirement and I imagine there’s some subtle difference with the way we used to save the session data that I’ve overlooked.
Thankfully this is pretty simple. Looks like this is a bug in the VST3 SDK that is fixed in 3.7.12 (we’re currently using 3.7.11) so I’ll update the SDK. The problem is that it unconditionally checks that the saved state has at a least 1 “program” but it should only do that if it’s saved as a bank. I’ll try and get a fix up today if I can. In the meantime if you want to try to apply the fix and test locally I’ve included a patch below.
JUCE-dev-11-22-41.patch (851 Bytes)
I have the same issue with the dev tip + patch here (still loading that reaper session that has a juce 7.0.12 vst2+vst3)
Hmm I’m not seeing any issues on my end with that fix applied.
Is it possible that after it didn’t load the correct state you’ve saved the session and it now has the wrong state in the session?
If that’s not the case could you please try putting a breakpoint on line 2913 of juce_audio_plugin_client_VST3. I’m expecting it to make it to line 2923. seekToBeginningOfStream() should return true, shouldTryToLoadVst2State() should return true, then readVst2State() should be called and I’m guessing VST3::tryVst2StateLoad() calls return {}; at some point, if you could let me know which line does that for you? or if any of the other functions fail?
If you’re saving a session with AudioPluginDemo instances maybe you could also try sharing the session on here and I’ll see if I can open it?
actually setState() isn’t even called. Reaper doesn’t found the matching vst3.
the reaper session:
vst2vst3test.RPP.zip (2.3 KB)
It seems the plugin code in your session is Dd0t it should be abcd to the best of my knowledge nothing to do with this has changed in any recent versions of JUCE, and I can’t reproduce your issue. Have you possibly played with the plugin code at some point? I’m fairly confident it’s not related to the issue we’re discussing.
