VST3/AU plugin hosting bugs - demonstration project

I’ve made/attached to this post as small and simple as possible demonstration of bugs related to VST/AU plugin hosting. These bugs seem to exist in both Mac and PC versions of JUCE. Here’s the list of bugs in the order of importance to me:

  1. JUCE doesn’t receive any keyboard events once you click the plugin GUI with mouse and try pressing keys on your computer keyboard. This happens regardless of what settings I set for keyboard focus for the plugin GUI and/or its parent Component.

This is a big no-no for me and needs some suitable solution fairly fast. Maybe JUCE could have a dedicated keyboard listener for VST/AU plugin GUIs which reacts to all key presses when plugin is in keyboard focus?

  1. Scanning and/or loading plugins leaks memory, as you can see from the debugger’s assertion failures when you exit the application.

The attached JUCE project tries receiving the keyboard events using the following methods:

    bool keyPressed(const juce::KeyPress &key) override;
    bool keyStateChanged(bool isKeyDown) override;
    bool keyStateChanged(bool isKeyDown, juce::Component* originatingComponent) override;
    bool keyPressed(const juce::KeyPress& key, juce::Component* originatingComponent) override;

If you want to try tweaking keyboard focus settings etc., you can find them from:
MainComponent.cpp, line 61
void MainComponent::setMouseAndKeyboardFocusSettings()

All help would be appreciated to solve this issue.

I used the JUCE 7.0.6, but this issue was already in version 7.0.5 when I first started implementing plugin support for my application.

VST_Host_Bugs.zip (11.3 KB)

I think that this is by design. If the plugin is focused, it gets to respond to key events first, and only unhandled key events should be passed up to the host.

Perhaps there’s scope for a new addGlobalKeyboardListener feature on juce::Desktop to mirror the existing addGlobalMouseListener - however, this would not be trivial to add and would require a lot of testing. I don’t see this happening in the near future as we’re currently focusing on other major features.

I haven’t checked the attached project, but the AudioPluginHost doesn’t exhibit this problem, so perhaps you could try checking out that project to see what you’re doing differently.

On my Mac the AudioPluginHost demo project has been working since it (for some reason) didn’t have VST3 plugin scan folders set into the project. As soon as I added the VST3 folder and told the application to scan the folder, AudioPluginHost crashed immediately, every time I told it to scan the VST3 plugins.

So AudioPluginHost seems to work well with AU plugins, but not with VST3s on Mac. At least that’s how it behaves on my computer, for some reason. Can anyone else verify if this same behavior happens also on other people’s Macs?

Also my own application which hosts plugins seems to work OK with AU plugins, but VST3s cause the leaking of that memory, but at least my application still manages to scan the VST3 plugins.

Here’s the code that tests scanning of the plugins of each available format. I’m making it run using triggerAsyncUpdate() since it was mentioned somewhere that doing otherwise would cause issues on Mac when some pop up windows appear on some plugin initializations.

    void handleAsyncUpdate() override
        juce::AudioPluginFormatManager m_plugin_format_manager;

        auto plugin_format_list = m_plugin_format_manager.getFormats();
        juce::File dead_mans_pedal_file(getApplicationDirectory().getChildFile(PLUGIN_LIST_CRASHED_FILE_NAME));
        for (auto& plugin_format : plugin_format_list)
            juce::PluginDirectoryScanner plugin_directory_scanner(m_full_known_plugin_list,
            bool keep_scanning = false;
            do {
                juce::String plugin_id;
                keep_scanning = plugin_directory_scanner.scanNextFile(true, plugin_id);
            } while (keep_scanning);

That’s very little code, so if there is some bug that is causing the leak, I hope it’s easy to point out.