Fail to set a state to UAD plugins under an older AudioPluginHost

1

Hi,
I found that AudioPluginHost of Juce version 6.0.8 (and below) is failing to set a saved state to UAD VST3 plugins, I double checked that setState is called with the correct data but still the plugins are loading in their default state.
All other VST3 plugins are loading fine with their previously saved state.

From Juce version 6.1.0 - AudioPluginHost is loading UAD VST3 plugins correctly with their saved state.

I need to maintain an application similar to AudioPluginHost which is still built using an older version of Juce and just apply the relevant fix on it to support loading UAD plugins with their saved state.

Upgrading to Juce 7 (or even 8) is indeed planned but until then we need to apply a hot-fix for this specific issue.

Is anyone familiar with this or can point me out where to look for?
I’m going over the changes between 6.0.8 to 6.1.0 but there are lots of them, didn’t nail it yet.
Thank you.

2

git bisect might help, assuming your project can build with all JUCE versions between 6.0.8 and 6.1.0.

The basic idea is that you’d navigate to the JUCE directory, then run

  • git bisect start # start the bisect
  • git checkout 6.0.8 # go to 6.0.8
  • git bisect good # normally you’d use bisect to locate regressions, so here ‘good’ means ‘not working’
  • git checkout 6.1.0 # go to 6.1.0
  • git bisect bad # ‘bad’ means ‘state restoration works’

Now, git will check out a sequence of commits. At each commit, you can build the AudioPluginHost and check whether state restoration works. If it does, run git bisect bad, otherwise run git bisect good.

After a few steps (fewer than 10 in this case), git will let you know that it’s found the first bad commit, which will be the one that fixed state restoration.

2 Likes
3

Thank you very much, I was not familiar with ‘git bisect’. It is a great tool making it very easy to perform binary searches.
So I found the relevant commit: VST3 Host: Ensure IEditController::setParamNormalized is only called
 · juce-framework/JUCE@9f03bbc · GitHub

This commit has many changes, but looks like deleting the following line resolved the bug I’m facing:

    editController->setComponentHandler (holder->host);

There were two calls to that function, one in: VST3PluginInstance::initialise and other in: prepareToPlay.
In the commit they removed the one from prepareToPlay and kept the one in initalise.
In my case I removed it from initialize as the bug still exists if removed from prepareToPlay.
Will check it further.
Thank you!

4

I understand why it’s necessary to use good and bad with the “opposite” meanings here, but would using old and new work instead? I’ve not actually “properly” tested this, but seems less confusing (if git would use old / new instead of good / bad in the status would have been even better for this case)

$ git checkout 6.0.8
$ git bisect start
$ git bisect old         # we're taking old to mean build is "broken"
status: waiting for bad commit, 1 good commit known
$ git bisect new 6.1.0   # and that new means build is "fixed"
Bisecting: 242 revisions left to test after this (roughly 8 steps)
[3399c34d0d5c6444072121d952540c9d75cdc982] Windows:  Fix more warnings emitted by clang with GNU-like command-line
# ... build current checked out code
# issue git bisect old|new depending if build was broken or fixed
# ... rinse/repeat

# when finished clean everything up:
$ git bisect reset
3 Likes
5

That’s cool, I didn’t know about the alternate old/new terms! Certainly less confusing.

1 Like