VST3 host can load the wrong plugin from WaveShell — class index goes stale after `setHostContext`

I ran into an issue with my mini host, Waveform has the same issue, so I think it’s a general juce bug with the hosting. If you try and open a Waves plugin, you get the wrong one. I tried to open “Saphira Stereo” from WaveShell1-VST3 17.1 but got “GW MixCentric Mono”

The issue is that WaveShell’s factory is not stable across `IPluginFactory3::setHostContext()`.

BEFORE setHostContext: countClasses = 718,
'Saphira Stereo' at index 487
AFTER setHostContext: countClasses = 1436
class at old index 487 is now: 'GW MixCentric Mono'
'Saphira Stereo' is now at index 974

The shell appends its edit-controller classes when the host context is set, and every class index shifts.

This is an issue because:

1. VST3ModuleHandle::create() resolves the class index via findClassMatchingDescription() when no host context has been set on the factory.

2. VST3ComponentHolder::initialise() then calls pf3->setHostContext(), the factory re-enumerates and instantiates via getClassInfo (classIdx) using the index found in step 1, which now points at a different class.

The name+uid matching itself is fine; it’s only the index that goes stale between the two steps.

The fix is to set the host context on the factory before searching for the class, so the index is resolved against the same factory state that initialise() sees (the second setHostContext call with the same context is then a no-op as far as ordering is concerned).

Fix is here: VST3 Host: Set host context on the factory before matching class indices · FigBug/JUCE@2fe1e52 · GitHub

Thanks for reporting, that’s fixed here: