So, I’ve got myself in a pickle. I’ve worked on this plugin for a long time and am planning to finally release it this year. So incorporating pamplejuce, and with it pluginval, I’ve run into a lot of bugs, most of which were easy to fix.
This last one is a funny one, it runs into a jassertfalse in juce_Singleton from ump::Endpoints::getInstance but only when testing the VST3. At the moment, I’ve been able to get to pluginval safety level 10 also on the VST3 by changing true to false in this line in juce_UMPEndpoints.h:
JUCE_DECLARE_SINGLETON_INLINE (Endpoints, true)
Now, of course there is a reason that it is true here, so that’s one reason of why I shouldn’t go down this path, and the obvious lack of practicality of modifying a git submodule a good second.
It seems that in VST3 mode, prepareToPlay seems to be called with a real sample rate, but then processBlock will be called with empty (numChannels == 0) buffers. Is there a way to do a non-full initialisation when that happens? Is there a good reason?
The reason I need to do a deviceManager.setMidiInputDeviceEnabled in my prepareToPlay (well called by that function anyway) is that my plugin has to be connected to a very specific set of midi devices, also receiving any CC etc which is otherwise not possible.