I’m a little surprised too, I will check, but that can be the problem with so many build flags.
Anyway thanks for reporting, I’ll get a fix up ASAP.
1 Like
Thanks for reporting, I’ve pushed a fix to develop.
1 Like
Thank you for the fix.
To be honest, I’m surprised by the size of this change. I don’t understand why fixing this simple conversion problem that could be solved with 1 line now led to moving the method around, adding std::optional and rewriting a whole block.
In my simple mind…: the more lines are changed, the more potential for collateral damage.
I don’t hope so… IMO what we need are more tests that make sure nothing breaks. Continous refactoring and code cleanups are important for keeping a framework alive and should not be risky. For this, the software design has to move forward to a more testable one.
Of course I agree with your reasonable arguments… I’m just annoyed by the recent chain of build-breaking changes in Juce 8 that cost me many hours of my limited dev time - just trying to do builds to send to beta-testers to finally fix all those bugs I see with June 8. It’s especially painful if it’s a change like the one leading to this thread that seems like it could have easily been postponed until the most glaring problems have been fixed.
So apologies to everyone for venting my frustration.
1 Like
The main reason was that there’s likely further changes to come after this. I realised in doing this, that only doing this for VST3_CAN_REPLACE_VST2 isn’t correct so this commit somewhat prepares for that change.
In general however I tend to take on the “Boy Scout rule” of software development in trying to leave code in a better state than I found it. Due to the changes that came before it, in retrospect that function should never have been left in that file which in turn removes the need to surround it with a preprocessor macro.
I’m sorry you’ve been impacted by changes to JUCE 8. The change that lead to this issue is potentially more important than you realise. There is a relatively serious issue for those that have released plugins with JUCE_VST3_CAN_REPLACE_VST2 enabled but without enabling JUCE_FORCE_USE_LEGACY_PARAM_IDS. There may not have been a lot of noise on the forums regarding this but we have heard from manufacturers who are experiencing issues relating to this and we have good reason to think this will become more of an issue going forward.
It’s worth highlighting that many of the larger changes to JUCE have been available since April and in the vast majority of cases we have resolved reported issues as fast as possible. So we had already held back these changes for some time and I was reluctant to hold them back any further.
After updating JUCE to a version (8.0.6) containing the commits mentioned on this thread, I’m running into issues with both the VST2 and VST3 appearing in Cubase (when before only the VST3 would show up), and with the VST2 crashing when try8ing to load it.
It seems like this is only happening on Intel Macs or when running Cubase under Rosetta (I still need to check Windows as well).
Has anyone else run into this? More info here: Crash when loading VST2 if VST3 is present