Logic "Pro" quantizes automation data for plugins to around 100 / 128 levels if you don't set the kAudioUnitParameterFlag_IsHighResolution flag for the parameter. Logic also won't automatically translate existing automation if you suddenly switch this flag on for an existing plugin, so the whole thing is pants - AU has specific support for enum / stepped parameters so I have no idea WTF this is even about, and why this flag it isn't already defaulted for all smooth params.
So when you write a new plugin I suggest you enable this flag:
Jeez, that's a library-developer's worst nightmare!
So if I add the flag by default now, new plugins will be fine, but existing ones will go wrong.
If I add a macro that you have to enable in order to set the flag, then people will need to know about it and remember to set it when appropriate, and most people will probably be unaware of its existence, or forget about it (I know I would!)
If I enable the flag by default but allow a macro to disable it, then everyone with existing plugins would need to know about this and disable it, which again is almost impossible to enforce!
Does this really break old plugins?
The way I understand it, the only incompatibility is that automation written with a plugin version without the flag set is still quantized.
That is my understanding of it as well. The automation that was once quantized will be forever quantized, but new projects created with an updated plugin (i.e. incorporating Andrew's fix) won't be quantized.
This will actually break existing automation. The automation I think jumps down by 100/125 = x0.8 in scale because of what is most likely an internal bug in Logic that doesn't detect if the plugin suddenly changes automation modes and adjust things properly. I think the best solution is to get Logic fixed so it looks out for and corrects its automation.
My solution has been to release two versions of the same plugin, since I can't wait for Logic to fix things. My older plugin The Glue doesn't really need hi-res automation, so I'm leaving it alone.
I think the issue needs to be raised with Apple / Logic, since there will be loads of plugins - not just Juce ones, in this boat. I know my friend Magnus is in the same situation, people complaining that his plugins can't be automated properly in Logic. Once the issue is fixed so that "flicking the switch" won't break existing Logic projects then it can be defaulted to on. I have no idea if any other host on the planet quantizes automation like this, I doubt it!
It seems that recorded automation data, always looks a little bit square-edged. Not sure is it because of the missing flag, or something which has to do of delayed event handling. This is what the demo-plugin produces
I don't want to bother anybody, but the only way to activate kAudioUnitParameterFlag_IsHighResolution, is to patching the AU-Wrapper. I think it wouldn't harm anybody if you implement the suggested change in the inital post.
I’m opening this up since there is:
‘JucePlugin_AUHighResolutionParameters’ is already here.
One suggestion would be adding it to new projucer built plug-in projects.
It should be default for new plug-ins to avoid compatibility breaking later on for new plug-ins.
Might be nice to add it as default with something as JUCE_FORCE_USE_LEGACY_PARAM_IDS
(I’d wish it was a single flag… but, still this could make hell for people not using it for newer products. the AU resolution is very bad without it).
Ok… so AUv3 is here (and still buggish ) but still would be nice for fellow JUCE5 users and upcoming plug-in release to have better resolution instead of the headache when their automation would break if they’ll even need it.
Might be new changes now should avoid this whole issue?
) but still would be nice for fellow JUCE5 users and upcoming plug-in release to have better resolution instead of the headache when their automation would break if they’ll even need it.