On this line of the VST3 process method there is a check for isWaveLab() via getHostType() getHostType checks the path of the current app file and then does a lot of string comparisons.
Not only will the string operations do a lot of allocations, the File::getSpecialLocation could well be some disk access.
This is showing up as process-block allocations during high-level pluginval validations.
I think this getHostType should either be cached as a JuceVST3Component member or maybe the getHostType generally should be cached as some static data. I’m not sure if it’s possible for that to change during operation?
(There’s also a similar call in the VST process block but at least that seems to only be called once.)
getHostType() in the VST3 wrapper is a function that holds its own singleton of PluginHostType, so it’s already cached as static data IMHO.
Probably the issue can be simply avoided by adding a call to that getHostType() during VST3 initialization, which makes sure that the PluginHostType singleton it contains gets initialized beforehand, and all subsequent calls during audio processing will simply query it.
Ah I see, the getHostType() it calls is in the juce_IncludeModuleHeaders.h, not the PluginHostType class and does indeed cache the result which was one of my suggestions above.
So yes, it looks like this just need an early call on the message thread to avoid the problem.
