VST3: JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE broken

It seems commit #e05a15 broke JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE for the VST3 wrapper.
This can be easily seen with Studio One 4.5 and saving a project with version before this commit and prior to this commit (just make sure you have #define JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE 1 always on.

The fix is simple:

-
-            if (! forceLegacyParamIDs && param.isDiscrete())
+
+            #if ! JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE
+            if (! forceLegacyParamIDs && param.isDiscrete())
+            #endif

I’ve also logged it on ROLI’s github as a comment to the commit.

2 Likes

Thank you for reporting. It looks like that commit confused forceLegacyParamIDs and JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE. We’ll get that fixed.

2 Likes

@t0m / @ttg
Sorry to comment on this older issue, but I’d like to understand what this was about exactly, as I’m also using that JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE flag for an older plugin.
(I tried to look through the code commit mentioned, but it apparently involved quite a lot of changes, so it’s not clear)

  1. What was the effect of this bug exactly when you saved with StudioOne? Was it so that after re-loading the project all saved automation was broken?
  2. And was it in the end only affecting the VST3 wrapper, or also AU and AAX plugins (the flag itself seems to affects all these 3 plugin types, according to its docs, but maybe it was only wrong for the VST3 wrapper)?

I would just like to check that this doesn’t occur with my recently updated plugin.

Thanks,
Koen

Automation usually related to parameters. Not save/load state.

You can look at the fix above/the juce code.
It was vst3 only wrapper.

1 Like