Do mouse and keyboard events need to be forwarded to embedded plugin GUIs?

[JBetz]

I'm using SDL to create a window for plugins to render on, and while I've been able to get the initial render to work correctly, the plugin doesn't respond to keyboard and mouse events. I assume this means that I need to forward events from SDL to the plugin, but there is no interface in the CLAP API to do so.

How is this supposed to work? Do frameworks like JUCE have some way of registering plugins in its top level event loop, or are plugins responsible for their own event loop? And if the latter, how are hosts supposed to give plugins time to process GUI events?

[baconpaul]

What’s your os and daw?

Mouse and keyboard are different and keyboard is tricky in some daws but basically yes you create a top level component which does a WM_MOUSE or the cocoa equiv or xembed so forth and that’s the component you return from gui create into the window object

if you are in Linux then folks generally use the clap posix fd and timer extensions to setup callbacks into their loops.

with keyboard some daws require settings to send kb events to the plugin

[JBetz]

What’s your os and daw?

OS is Windows. And I'm building the DAW. :)

The basic architecture is a SDL frontend talking to a Haskell backend (https://github.com/JBetz/ensemble). Windows are created by SDL and then the Win32 window handle is passed to the backend for calls to CLAP's create() method.

Mouse and keyboard are different and keyboard is tricky in some daws but basically yes you create a top level component which does a WM_MOUSE or the cocoa equiv or xembed so forth and that’s the component you return from gui create into the window object

I should have clarified that I'm asking about plugin hosts, and not plugins themselves. It sounds like you're describing how plugins set up their own event loop? Otherwise, I don't know what you mean by "the component you return from gui create".

[baconpaul]

Well I more meant hownplugins collaborate with the host.

Plugins return a native element (HWND nswindow etc) which the daw parents into a component - a top level window or a compound component of its own form - and then the standard event loop mechanisms work.

Juce shows an example of this but so does the clap host here which uses qt to show a window.

I have no idea how you do that with sdl though.

[baconpaul]

Sorry of me be a bit more precise

the plugin gets handed an HWND nswindow erc and then it is the plugin responsibility to add itself to that component

clap/include/clap/ext/gui.h

Line 178 in 41964fa

bool(CLAP_ABI *set_parent)(const clap_plugin_t *plugin, const clap_window_t *window);

so the daw job is to create an appropriate os level container with events erc and then pass it to the plugin using that api. My prior comment had the creation order a bit upside down (since plugins generally make a component of their own to reparent into that element)

[baconpaul]

And a quick google shows (https://stackoverflow.com/questions/24117983/get-window-handle-of-sdl-2-application)

SDL_SysWMinfo wmInfo;
SDL_VERSION(&wmInfo.version);
SDL_GetWindowWMInfo(window, &wmInfo);
HWND hwnd = wmInfo.info.win.window;

that will get you an HWND from an SDL thingy. In theory you should be able to create a window and call that and then pass that HWND to set parent and voila.

I am sure there are lots of steps after voila, but that's the kinda thing you are looking to do I think. Then the window loops should all merge?

Sorry if this isn't helpful. Curious if you get it working how you did.

[JBetz]

that will get you an HWND from an SDL thingy. In theory you should be able to create a window and call that and then pass that HWND to set parent and voila.

Yup, that's how my DAW's frontend is getting the window handle. And then SDL starts pumping events to that window. I think the problem is that it's pumping SDL events, not Win32 events, so I need some sort of conversion layer.

The other option is to add SDL to the plugin spec, but from cursory research I got the impression it isn't well-equipped for plugin development and so probably wouldn't get used. Hopefully SDL3 is solving some of those problems.

Sorry if this isn't helpful. Curious if you get it working how you did.

It's helpful in confirming that I was going in the right direction, so thanks for that!

[baconpaul]

One thing you could do is just not have embedded plugin windows. That is, write a tiny bit of WIN32 to open an entire new top level window and host in there as a popout. Bespoke uses that strategy (it even uses Juce windows) and basically so does Logic and Live. May be something which could make your life a lot easier?

[JBetz]

Yup, it does. And that's more or less what I'm trying to do, create a floating window / popup using CLAP's embedded GUI API. I hadn't thought of just using Win32 for the plugin windows, though. That's a good idea, thanks!