Ouch! kAudioUnitParameterFlag_IsHighResolution problem, fix needed!

Audio Plugins
1

My old plugin used the macro JucePlugin_AUHighResolutionParameters to explicit set the flag kAudioUnitParameterFlag_IsHighResolution for to allow fine high resolution automation in logic.

Years ago, I ported this plugin to the latest JUCE Version and therefore I needed to set JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE

Because of this and the commit below, the result is that my plugin doesn’t support high resolution parameters any more :frowning: That actually wasn’t so cool!

@tpoole

The macro was removed from the codebase. It would be cool if in the future if there would be at least an #error if a macro which has some kind of function is removed.

But the real problem is here →

There is currently no way to rebuild support for HighResolutionParameters via JucePlugin_AUHighResolutionParameters for plugins which are using JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE

So it would be cool if the flag will be re-introduced:

diff --git a/modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm b/modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm
index 4193ebbf6..bf805ba91 100644
--- a/modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm
+++ b/modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm
@@ -909,7 +909,7 @@ ComponentResult GetParameterInfo (AudioUnitScope inScope,
                                                     | kAudioUnitParameterFlag_HasCFNameString
                                                     | kAudioUnitParameterFlag_ValuesHaveStrings);
 
-               #if ! JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE
+               #if (! JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE ) || JucePlugin_AUHighResolutionParameters^M
                 outParameterInfo.flags |= (UInt32) kAudioUnitParameterFlag_IsHighResolution;
                #endif

Thanks

2

This is a nightmare :exploding_head:

After I re-introduced the flag the automation parameters are interpreted differently than before.

The flag JucePlugin_AUHighResolutionParameters should have never had been removed in first place, this was a big mistake!

Its a widely used plugin, and half of my customers use the version where JucePlugin_AUHighResolutionParameters is working and and the other half where JucePlugin_AUHighResolutionParameters has no effect because (JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE is true)

What are my options now? Any help appreciated.

1 Like
3

+1 for this, at least a warning message for removed macros would be appreciated. It would make easier for developers to be aware that the functionality behind he macro has been removed or implemented differently, and that gives a better chance to declutter code removing defs that no longer have effect.

2 Likes
4

Thanks for your support.

I seems Logic determines this flag only when the plugin is initially scanned (And that happens only if the binary is created/copied, but not moved by finder) (even if it calls GetParameterInfo() more frequently ). So a dynamic switch inside the plugin isn’t a solution, also there is no way to determine if the recalled project used the flag. It’s complicated.

A second plugin with another plugin-ID wouldn’t solve the problem with old projects.

The only idea I have is to give the user to switch the behaviour in the setup, which is far from perfect, because automation data in existing project will be different. I also need to custom modify the AudioUnit-wrapper, to read a configuration file.

This is all very unsatisfactory. If anyone has a better idea, also someone from the juce-team, I would be grateful.

5

We’ve made this a while ago.

If you can detect the save state version / you store the plug-in version, you might be able to warn the users.

Prior to version 6, JUCE was very much mixed bag of parameters. Including VST3 normalizations, vst2-3 interchangable parameters, studio one flags, stepped parameters.
It takes quite a lot of resources to properly test builds to make sure automation doesnt break.

Good luck.

6

Thanks, unfortunately I cannot determine which exactly version of my plugin is used from the state.
Also, I think I have checked, setting the High-Res flag at runtime isn’t really working reliable, when you opening different projects.

It takes quite a lot of resources to properly test builds to make sure automation doesnt break.

Yes absolutely.

When I upgraded to the latest juce, i carefully tested automation compatibility against different hosts, I also found some serious issues in the VST to VST3 transition in Studio One which I reported to them and which become fixed.

Somehow the current issue was my blind spot, because I thought this was “already fixed” through the JucePlugin_AUHighResolutionParameters macro.

Anyway, it seems I have an unsolvable problem here. Will try to communicate it openly with my customers, and hope for the best.

7

I have to correct myself.

It looks like the highResolution-Flag is dynamically hot switchable, for each plugin instance.

So I can save the current highRes-modus in the state, and switch it on/off, to create a compatibility mode inside the plugin GUI.

I can use a callback like proposed from ttg, to receive the current state per plugin instance.

updateHostDisplay() causes logic to rescan the parameter flags, and even updates the automation lane in the GUI

    void setForceHighResolution(bool useHighResolution)
    {
       if (forceHighResolution!=useHighResolution)
       {
           forceHighResolution = useHighResolution;
           updateHostDisplay(AudioProcessorListener::ChangeDetails().withParameterInfoChanged(true));
       };
    }

In the Wrapper:

if (juceFilter->forceHighResolution)
{
       outParameterInfo.flags |= (UInt32) kAudioUnitParameterFlag_IsHighResolution;
}
1 Like