I thought we had our legacy (pre-JUCE) AudioUnit sessions loading with our JUCE (5.3.2) plugins, but we found another issue with the automation data, at least in Logic. (I think it’s ok in Studio One, but need to make a legacy session there to test again.)
While our automated parameters are now showing up correctly, the values that the automation lanes display for their previously recorded automation is incorrect for discrete parameters. It seems that the old data, for discrete parameters, used the “world” values, meaning the actual indexes into the discrete lists of values, rather than the “normalized” values which range from 0.0 to 1.0. This means that every automation value that is greater than 1 gets pinned to 1.0 when the automation data is displayed in the automation lanes.
Since we are never given any access to the automation lane values when loading a saved session, we have no opportunity to decide if the data is for a discrete parameter from old or new session data, and thus all data for discrete parameters gets mapped to either 0 or 1 in the automation lanes.
How can we modify our custom AU wrapper code so that old automation data is correctly mapped?
Is it just the text labels that are displaying incorrectly, or is the automation data controlling the parameters incorrectly?
Can you write out new automation data in the same way as the old, or do you need compatibility with both previously recorded new and old data?
The places to look are
getMaximumParameterValue and everywhere it’s used.
It’s the values that were apparently written to the automation lanes that are the issue. I can see that the lines in the lanes are incorrect. The labels match the lines, but they are “pinned” to either the minimum value or the maximum value. So, an index of 0 in the old version now shows as a 0 in the new version (which is correct), but any index 1 or greater shows as the last index, because the old data appears to have been written using the index values, not the normalized [0.0…1.0] range.
The parameters themselves work as expected with the controls, and record automation correctly.
Studio One works correctly, showing the automation data across its full range as expected. It seems like Logic recorded the automation differently.
I don’t know how we could possibly write our new automation data in the same manner as the old version apparently did, because we’re not in charge of what a host records, only how we define our parameters, and we define them as discrete parameters with a set number of values.
I will look for getMaximumParameterValue and see what I can find there, thanks.
We’re running into similar problems, moving from 5.2.1 to 5.4.3.
Comparing the implementation in
juce_AU_Wrapper.mm, following can be noted:
static constexpr bool forceUseLegacyParamIDs = true;
static constexpr bool forceUseLegacyParamIDs = false;
float getMaximumParameterValue (AudioProcessorParameter* param)
return param->isDiscrete() && (! forceUseLegacyParamIDs) ? (float) (param->getNumSteps() - 1) : 1.0f;
5.2.1 and older
float getMaximumParameterValue (int parameterIndex)
return juceFilter->isParameterDiscrete (parameterIndex) ? (float) (juceFilter->getParameterNumSteps (parameterIndex) - 1) : 1.0f;
To me this would seem that the macro here is not the correct one. Up until now we’ve relied on setting
JUCE_FORCE_LEGACY_PARAM_IDS as false and
JUCE_FORCE_LEGACY_AUTOMATION_TYPE as true, as that produces the correct recall. Changing the implementation to the way it used to be for that one function would seem to solve the issue for us.
@t0m any takes on this, is the use of different macro intentional, or is there something I’ve not understood about this? Thanks!
That doesn’t look right… I’ll reinstate the older behaviour.
I’m having a problem with AU parameter recall, so this came up in a search. I’m confused by this thread, as if I look at the current [5.4.4] code in juce_AU_Wrapper.mm`, it looks the same as the code which is supposed to have been changed?