VST3 plugin editors render but do not receive mouse input in Apleton Live 12.4.6 (Windows)

Audio Plugins
1

Hi,

I’m developing a VST3 plugin using JUCE 9.0.3 and Visual Studio 2022 on Windows. The plugin editor renders correctly in Ableton Live 12.4.6, but it does not receive mouse input.

I’ve isolated the problem to Ableton Live by testing both my plugin and the official JUCE AudioPlugin example.

Environment

  • Windows
  • Ableton Live 12.4.6
  • JUCE 9.0.3
  • Visual Studio 2022
  • VST3
  • CMake build

Reproduction

I built the official JUCE CMake AudioPlugin example from:

JUCE/examples/CMake/AudioPlugin

I added the JUCE source tree with add_subdirectory() and built the example as a VST3.

I then tested the resulting VST3 in:

SAVIHost

  • Plugin editor opens.
  • JUCE controls work.
  • A JUCE Slider responds correctly to mouse interaction.

Ableton Live 12.4.6

  • Plugin editor opens and renders correctly.
  • JUCE controls do not respond to mouse interaction.
  • A JUCE Slider cannot be clicked or dragged.
  • Overriding mouseDown() on the editor produces no response.

The same behavior occurs with my own JUCE VST3 plugin.

Additional test

I also tested my own plugin in SAVIHost:

  • Editor renders: yes
  • Mouse input: works

Therefore the same plugin binary receives mouse input correctly in SAVIHost but not in Ableton Live.

Editor rendering

The JUCE editor’s paint() method is called normally in Live, so the editor is definitely being created and rendered.

However, mouse interaction does not reach the JUCE component hierarchy.

For example, I tested:

void AudioPluginAudioProcessorEditor::mouseDown(const juce::MouseEvent&)
{
    setColour(juce::ResizableWindow::backgroundColourId,
              juce::Colours::red);
    repaint();
}

Clicking the editor in Live does not trigger this.

I also tested an actual JUCE Slider, and it does not respond to mouse interaction.

Ableton settings

I also disabled Ableton’s GPU Renderer and completely restarted Live.

The behavior did not change.

Conclusion

This appears to be specific to the interaction between Ableton Live 12.4.6 and the Windows VST3 editor window/component handling, rather than an issue with my plugin implementation.

Could anyone confirm whether this is a known Live 12.4.6 issue, or whether there is a Live/VST3 editor setting or Windows configuration that can cause a VST3 editor to render correctly while receiving no mouse input?

The particularly useful part of the reproduction is that the official JUCE AudioPlugin example behaves the same way, while the same example works correctly in SAVIHost.

Thanks.

2

Hi, thanks for the bug report.

I tried reproducing the issue by taking the following steps:

  • Check out JUCE’s develop branch
  • Clear the content of the AudioPluginExample’s PluginEditor.cpp, and replace PluginEditor.h with the following content:
class AudioPluginAudioProcessorEditor final : public juce::AudioProcessorEditor
{
public:
    explicit AudioPluginAudioProcessorEditor (AudioPluginAudioProcessor& p)
        : AudioProcessorEditor (&p), processorRef (p)
    {
        setSize (400, 300);

        addAndMakeVisible (slider);
    }

    void resized() override
    {
        slider.setBounds (getLocalBounds().withSizeKeepingCentre (200, 100));
    }

    void paint (juce::Graphics& g) override
    {
        g.fillAll (pressed ? juce::Colours::cyan : juce::Colours::magenta);
    }

    void mouseDown (const juce::MouseEvent&) override
    {
        pressed = true;
        repaint();
    }

    void mouseUp (const juce::MouseEvent&) override
    {
        pressed = false;
        repaint();
    }

private:
    AudioPluginAudioProcessor& processorRef;
    bool pressed = false;
    juce::Slider slider;

    JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (AudioPluginAudioProcessorEditor)
};
  • Build the VST3 (I’m using VS2026 on Windows 11 26H2)
  • Run Ableton Live 12.4.6 and add the plugin on a track
  • Interact with the editor using the mouse pointer

I’m seeing the expected behaviour, i.e. mouse clicks are registered by the plugin editor:

In short, I’m not able to reproduce the behaviour you described.

To make progress on this issue, it would be helpful to know:

  • What JUCE version are you using for testing?
  • What Windows version are you using for testing?
  • Is it possible that Live is displaying some other modal window that is blocking mouse events from reaching the plugin? Perhaps some other plugin displays a license-checking window that prevents input from reaching your plugin. Note that hosts live Live may instantiate plugins in order to scan them, so it’s possible for a badly-behaved plugin to steal input focus even before the user adds that plugin to a track.
  • Is there anything unusual about your testing computer? Does it have multiple monitors, or a rare GPU, or anything else out of the ordinary?
  • Related: is it possible for you to test the behaviour on a separate computer? Do you still see the same behaviour there?
3

Thanks for looking into this. I have some additional test results.

System configuration

  • Windows 11 Pro 25H2

  • JUCE 9.0.3

  • Ableton Live 12.4.6

  • Intel Core 5 120U

  • Integrated Intel graphics

  • Multiple monitors

Updated reproduction results

I tested both my own VST3 plugin and the official JUCE AudioPlugin example.

  • SAVIHost: Both plugins work correctly, including mouse interaction.

  • Ableton Live 10: The plugin editor works on my main PC monitor, but mouse interaction stops working when I move the editor to my second monitor.

  • Ableton Live 12.4.6: The same behavior occurs. The editor works on my main monitor but does not respond to mouse input on the second monitor.

I also noticed a significant performance difference: the plugin editor runs smoothly in Live 10, whereas in Live 12.4.6 it becomes extremely slow, at approximately 3 FPS.

I previously disabled Live’s GPU Renderer, but this did not resolve the mouse-input issue.

The fact that both the official JUCE example and my own plugin exhibit the same behavior suggests this is not specific to my plugin implementation.

Could this be related to Windows multi-monitor DPI scaling, mouse-coordinate handling, or graphics rendering with integrated Intel graphics? Are there any additional diagnostics or settings you would recommend checking?

I can provide the monitors’ resolutions, scaling percentages, and refresh rates if useful.