Old DAW project plug-in state recalled in VST but not in AU

I’ve converted a plug-in which was originally developed using the VST2 SDK to use JUCE. I’m finding that the VST build works fine (on Windows and macOS) but the AU build doesn’t recall it’s original state when loaded into an old, pre-JUCE DAW project. It does recall it’s state correctly if I save a new project. I’ve tried defining JUCE_FORCE_USE_LEGACY_PARAM_IDS to 1 but this doesn’t make any difference (assuming I’m doing it right.)

Note that the original AU was done using Symbiosis, if that’s of any relevance.

There are a number of different ways of storing/communicating AU parameter values, so I suspect you’ll have to really dig into the code to work out what’s going on.


So I’ve tried JUCE_FORCE_USE_LEGACY_PARAM_IDS and JUCE_FORCE_LEGACY_PARAMETER_AUTOMATION_TYPE both separately and together with no effect. I was under the impression that the differences between plug-in formats were handled by JUCE code, in which case could you give me a clue which code I should dig into?

The differences between plug-in formats are handled by JUCE. The problem you’re running into there is that the data produced by the previous version of your AU is incompatible with your new JUCE-based AU.

A plug-in is completely free to decide how it stores its state. This is what happens in JUCE’s getStateInformation and setStateInformation. Since your new JUCE-based VST implementation seems to be recalling state from your previous implementation correctly, then I assume you’ve previously been saving your state in a fixed form which you are now reading correctly. It’s not completely clear from your post if you’ve checked this is working for your AU, but this is the place to start diagnosing things.

Then there are parameters.

There are different ways to index your parameters. You can chose from a simple integer index or a hash-based approach. It’s up to the plug-in to specify how to do this and if your previous plug-in was using a different scheme then the indices will be wrong. JUCE_FORCE_USE_LEGACY_PARAM_IDS may go some way to addressing that, but that handles moving back to the way JUCE used to to things, which is not necessarily how the previous version of your plug-in does things.

Once you’ve got your parameter IDs lined up there are other things that might need lining up.

For example, if an AU parameter is discrete then it can have the kAudioUnitParameterUnit_Indexed property defined - this enables hosts to display the automation as a series of steps. However, this also means that the plug-in needs to send integer parameter values to the host (one for each step), rather than a 0.0->1.0 float. So when automation is played back you will get integer values, not a normalised float.

There are other flags like kAudioUnitParameterFlag_CanRamp and kAudioUnitParameterFlag_IsHighResolution that affect how automation data is recorded.

Using auval might shed some light on the differences between your old and new plugins. You’ll be able to see their IDs and some of their properties. Otherwise the next step would be sticking some logging into juce_AU_wrapper.cpp to monitor the values you’re receiving from the host and making sure they’re what you expect.

1 Like