🎛️ Uhbik Wrapper – Free VST3 Effect Chain Host (Open Source)

[Urs]

Very cool!

A suggestion for the road map if I may: a few global LFO's/modulators that can be bound to the macro knobs.

Ooh! Yes, please!!

Noooooo

[audiojunkie]

Very cool!

A suggestion for the road map if I may: a few global LFO's/modulators that can be bound to the macro knobs.

Ooh! Yes, please!!

Noooooo

[NAD]

Works with Uhbik *and* any other VST3 effects

Kinda buried the lead there a little bit....
Congratulations, this looks pretty nice!

[Urs]

A suggestion for the road map if I may: a few global LFO's/modulators that can be bound to the macro knobs.

Thanks, can it also host CLAP now too?

If it hosted CLAP, it could send LFOs etc to any knob using CLAP's Parameter Modulation feature with granularity of 64 samples.

[dlarseninclusive]

A suggestion for the road map if I may: a few global LFO's/modulators that can be bound to the macro knobs.

Thanks, can it also host CLAP now too?

If it hosted CLAP, it could send LFOs etc to any knob using CLAP's Parameter Modulation feature with granularity of 64 samples.

```
I am having a hard time with mouse clicks making it through on the CLAP plugins. If you have any ideas?

CLAP Plugin GUI Hosting Issue on Linux/X11 (JUCE-based host)

Environment:
- Host: JUCE-based VST3 plugin that hosts other plugins (effect rack)
- Platform: Linux (X11, not Wayland)
- CLAP SDK: 1.2.0
- Plugins tested: u-he Uhbik suite (CLAP versions)

What works:
- CLAP plugin loading, activation, audio processing ✓
- State save/restore ✓
- GUI rendering (plugin UI appears correctly) ✓
- VST3 versions of the same plugins work perfectly with full mouse interaction ✓

What doesn't work:
- Mouse events don't reach the CLAP plugin GUI
- Knobs don't respond to clicks/drags

Technical details:

Using the CLAP GUI extension to embed the plugin UI:

gui->is_api_supported(plugin, CLAP_WINDOW_API_X11, false); // returns true
gui->create(plugin, CLAP_WINDOW_API_X11, false); // embedded mode
gui->get_size(plugin, &width, &height); // correct size
gui->set_parent(plugin, &window); // renders into parent
gui->show(plugin); // UI visible

The plugin successfully creates a child X11 window inside the parent window
(confirmed via XQueryTree). The GUI renders perfectly, but mouse events never
reach it.

Approaches tried:
1. Raw X11 window (bypassing JUCE)
- XCreateWindow passed to plugin
- GUI renders, but no mouse events

2. JUCE window
- setInterceptsMouseClicks(false, false)
- Same result

3. Floating mode
- gui->create(plugin, api, true)
- u-he returns is_api_supported = false for floating on X11

4. XSendEvent forwarding
- Intercepted JUCE mouse events
- Forwarded via XSendEvent to child window
- Plugin ignores synthetic events

Root cause hypothesis:
JUCE's X11 event loop processes all events for windows in its hierarchy before
they can reach embedded child windows. The plugin's X11 window never receives
native mouse events because JUCE consumes them at the application level.

Questions:
1. Does u-he's CLAP implementation expect specific X11 properties on the parent
window (e.g. XEmbed protocol)?
2. Is there a way to make the plugin handle events differently on Linux?
3. Do other CLAP hosts on Linux successfully embed u-he GUIs?

Any insights appreciated!

[Urs]

Have you set up the timer that is required on CLAP/Linux which acts as a user thread timer on Win/macOS?

[Urs]

Here's what the latest and greatest computer says, after cross-referencing the bug report with our codebase:

What's most likely happening

On Linux/X11, "GUI renders but gets no mouse" almost always means: the embedded child window exists, but the plugin's X11 event processing never runs (or can't see the events), not that JUCE "steals" events in a way you can fix with setInterceptsMouseClicks(false, false).

In CLAP, the host does not forward mouse events through the CLAP API. Instead, the plugin is expected to receive native X11 events via the normal X11 mechanism and to run an event loop of some sort to process them. Because plugins can't own the host's main loop, CLAP provides the POSIX FD support (and optionally timer) extensions so plugins can ask the host to call them back when X11 events are pending.

This is explicitly reflected in CLAP ecosystem guidance:

• The CLAP GUI API for X11 says embedding is done via XEmbed. (CLAP_WINDOW_API_X11 references the XEmbed spec in clap/ext/gui.h.)
• The CLAP tutorial's X11 example sets _XEMBED_INFO and registers the X11 connection FD with the host so the host calls back when events are ready; otherwise the plugin won't process events. (It uses ConnectionNumber(display) + clap_host_posix_fd_support.register_fd().)

So if your host does not implement clap.host-posix-fd-support (and pump it on the main thread), many plugins will still be able to paint (because rendering can happen on expose/initial draw), but won't respond to input because they never dispatch X11 events.

What the host is missing (most probable)

1) Implement clap.host-posix-fd-support properly
The host must provide the clap_host_posix_fd_support_t extension and actually integrate it into its main-thread event loop:

• register_fd(fd, flags): store the FD and watch it (readable/write/error).
• When the FD becomes ready, call the plugin's clap_plugin_posix_fd_support.on_fd(plugin, fd, flags) on the main thread.

In a JUCE host on Linux, a practical approach is:

• Maintain a list of registered fds.
• Use JUCE's Linux message loop integration (or a periodic timer) to poll() those fds.
• When poll() indicates readable, call on_fd.

If this is missing today, that matches the symptom perfectly: UI visible, no knob interaction, and even "raw X11 window" doesn't help.

2) Don't rely on XSendEvent
Many UIs ignore synthetic events for good reasons (security / correctness). So the "forward JUCE events via XSendEvent" path being ignored is expected and not a u-he bug.

3) XEmbed properties/focus may still matter, but are secondary
Some hosts are strict about XEmbed. The plugin side usually sets _XEMBED_INFO, but you should ensure:

• The embedding container is compatible with XEmbed expectations (reparenting, mapping, focus handling).
• Focus is handled sanely (keyboard focus especially). Mouse typically works without special focus, but some toolkits couple drag tracking to grabs/focus.

However, given mouse doesn't work at all, the FD/event-dispatch issue is the first thing I'd fix before chasing XEmbed quirks.

What u-he is likely not missing

• u-he's CLAPs working in other Linux hosts strongly suggests their side is fine.
• Their refusal of "floating on X11" (is_api_supported(..., is_floating=true) == false) can be an intentional limitation and is allowed by CLAP. It's unrelated to embedded-mouse not working.

Direct answers to his questions

1) "Does u-he expect specific X11 properties (XEmbed)?"
Possibly, but the bigger expectation is: a real X11 event loop path. XEmbed details are important for robustness (focus, mapping), but they don't replace dispatching X11 events.

2) "Is there a way to make the plugin handle events differently?"
Not via CLAP host API. There is no "deliver mouse events" function. On Linux, the plugin typically uses X11 directly and depends on the host to provide POSIX FD support so it can process X11 events on the main thread.

3) "Do other CLAP hosts on Linux successfully embed u-he GUIs?"
Yes—at minimum Bitwig does (u-he + Bitwig are CLAP co-creators). Also, reference hosts like clap-host (Qt-based) implement the proper infrastructure.

Actionable checklist for the JUCE host author

• [Implement] clap.host-posix-fd-support in the host.
• [Verify] The plugin actually exposes clap.plugin-posix-fd-support and calls register_fd() when GUI is created.
• [Integrate] The registered fds into JUCE's main thread loop (poll/select; then call on_fd).
• [Confirm] The plugin's child X11 window is created and the X11 connection FD is being serviced.
• [Then check] XEmbed/focus:
  • parent window mapping and stacking
  • focus-in/out behavior (especially for keyboard)
  • no host-side grabs that prevent child from receiving pointer events (rare but possible)

Status

• Conclusion: This is overwhelmingly likely a host-side missing CLAP POSIX FD event dispatch (and possibly incomplete XEmbed/focus handling), not something missing in your plugins.
• If you want, paste the host's CLAP host-extension list / implementation snippet (what it returns from get_extension()), and I'll tell you exactly which extension(s) are missing and how to wire them into JUCE's Linux loop.

(sorry, formatting for code is different in KVR... made it italics instead...)

[dlarseninclusive]

Have you set up the timer that is required on CLAP/Linux which acts as a user thread timer on Win/macOS?

Bingo! TY!

We implemented both clap.host-posix-fd-support AND clap.host-timer-support.

The POSIX FD support was already present, but timer support was missing.

Once we added timer support and began firing on_timer() callbacks at the
plugin’s requested period (33 ms), mouse interaction started working.

The plugin appears to rely on the timer callback to pump its X11 event queue.

[dlarseninclusive]

Works with Uhbik *and* any other VST3 effects

Kinda buried the lead there a little bit....
Congratulations, this looks pretty nice!

Maybe lol, Thank you

Since the purpose is to enable Uhbik to have full presets spanning the collection I thought I would stick with that. It being a multi purpose plugin host is a side effect. I wanted this so I can give it away with a library.

After this is fully production ready I will certainly review the idea again and put that up front.

[Urs]

Have you set up the timer that is required on CLAP/Linux which acts as a user thread timer on Win/macOS?

Bingo! TY!

We implemented both clap.host-posix-fd-support AND clap.host-timer-support.

The POSIX FD support was already present, but timer support was missing.

Once we added timer support and began firing on_timer() callbacks at the
plugin’s requested period (33 ms), mouse interaction started working.

The plugin appears to rely on the timer callback to pump its X11 event queue.

[Tj Shredder]

This is wonderful. I wonder if that code could also host AUv3. Now we have a lot of AUv3 plugins coming from iOS or iPadOS that run also on a Mac. And beside hosting all sorts of FX plugins, how hard would it be to host also instruments?
I do have Bidule which can do all of that, but having an open source alternative is something which might even make things easier…

[dlarseninclusive]

This is wonderful. I wonder if that code could also host AUv3. Now we have a lot of AUv3 plugins coming from iOS or iPadOS that run also on a Mac. And beside hosting all sorts of FX plugins, how hard would it be to host also instruments?
I do have Bidule which can do all of that, but having an open source alternative is something which might even make things easier…

I'll look I to AU and possibly add it to the road map. Instruments are filtered out, that itself is easy to toggle. Not tested at all, and probably will not be able to anytime soon. Thanks for the feedback.

[Dirtgrain]

Might this plugin wrapper be made multi-band, like Kilohearts Multipass? It would fill a long-standing desire for me.

[dlarseninclusive]

Might this plugin wrapper be made multi-band, like Kilohearts Multipass? It would fill a long-standing desire for me.

That is a great idea. I'll add that to the roadmap.

[dlarseninclusive]

UhbikWrapper Update - March 2026

New features landed:

Multiband processing — MAIN/LOW/MID/HIGH tabs let you run independent effect chains per frequency band. Linkwitz-Riley 24dB/oct crossovers, per-band solo/mute/gain, adjustable crossover frequencies.
Instrument hosting — You can now load synths and samplers, not just effects. (Stand alone for now)
Plugin type filter — New dropdown to filter the plugin list by All/Effects/Instruments.
Alphabetical sorting — Plugin list is now sorted A-Z.
Audio thread optimization — Zero-allocation processing path, pre-allocated band buffers.
Builds available for Linux, Windows, and macOS on the releases page.

Shout out to Maarten (GitHub issue #2) for the instrument hosting and sorting request, and Dirtgrain for the multiband idea.