Plans to make this work within web browsers?

[BenAlthauser]

It would be really cool (if this isn't going on already) to have a simple bridge that could allow CLAP plugins to run within the web browser, something like maybe https://www.webaudiomodules.org/ is doing, using web assembly. Would something like this be possible, or is it being considered?

[LibrarySeph]

This would be amazing. Little by little, web browsers are creating open standards for every modern computer interaction. The overall goal is that they should be capable of most any interaction an OS can do. Being able to integrate CLAP into a browser environment would vastly lower the entry level for building your own DAW. It would also likely lead to a slew of new open-source DAWs being built, with CLAP plugins being the work horses.

Compiling a CLAP to WASM alone would not be enough, there would also need to be some basic loader interface which could convert the plugins to a child of AudioNodes. I'm going to dare to dream for a moment, and outline what would be an amazing imaginary interaction:

// Not real code, for those who skim read this isn't real.
const audioCtx = new AudioContext();

const clapLoaderWasm = await WebAssembly.instantiateStreaming(fetch("CLAP_Loader.wasm"), importObject);
const clapLoader = clapLoaderWasm .instance.exports;

//type ClapAudioNode = AudioNode & {
//  renderUI(): HTMLCanvasElement;
//  getParam(id): ParamObject;
//}

const plugins: ClapAudioNode[] = await clapLoader.load("./root/path/", ["eq.clap.wasm", "osc.clap.wasm", "valhalla_reverb.clap.wasm"]);
const [eq, osc, valhalla] = plugins;

osc.connect(valhalla);
valhalla.connect(eq);
eq.connect(audioCtx);

document.body.append(osc.renderUI());

If parameter states were exposed, one could even go so far as to build a web UI to control each plugin.

[abique]

This is interesting.

I'd like to have clap plugins compiled to wasm and instantiated with a canvas/webgpu and web user input (mouse/keyboard/touch).

[LibrarySeph]

CLAPs are entirely self contained by design, right? Like, they shouldn't need to access any external libraries?

My cursory understanding of gui.h leads me to believe that hosts are capable of consuming plugin drawing buffers for the sake of inline embedding. If this is true, then a "CLAP_Loader.wasm" might be able to route drawing buffers to HTMLCanvas. If plugins manage their own windows, it seems like routing draws to canvas would require messing with the ui frameworks. Maybe, I haven't researched much.

Do you know how possible it is for a host to get between a user and a plugin? For instance, could a host simulate interaction events (not through exposed params), or layer a shader over a plugin?

[baconpaul]

There’s no such constraint on claps. They can dynamically link anything. Generally that results in a badly working clap but there’s nothing in the spec which requires or mandates they are self contained.

at source time they will link lots of things but usually statically

gui.h is purposefully a tiny api. You are handed a pointer to a display type (hwnd, nsview, etc) and then can do whatever you want with it. Many plugins use juce iplug or vstgui to realize their ui and event stream on top of this os level primitive

[LibrarySeph]

So, if I understand correctly, it should be theoretically possible for a WASM based loader to host a WASM based CLAP, and then hand it a pointer to a display type which it can then draw on?

They can dynamically link anything
I suppose they tend to dynamically link OS specific drawing stuff, right? That seems like it would be necessary if they're being handed OS specific display types.

[Trinitou]

So, if I understand correctly, it should be theoretically possible for a WASM based loader to host a WASM based CLAP, and then hand it a pointer to a display type which it can then draw on?

They can dynamically link anything
I suppose they tend to dynamically link OS specific drawing stuff, right? That seems like it would be necessary if they're being handed OS specific display types.

I have no clue about wasm. But if its possible at all, it should be not too difficult to build a very basic minimalistic wasm-based clap: first without any extension, then maybe only with the log extension for printing stuff to the host and as a proof-of-concept then try to do something with the GUI extension (https://github.com/free-audio/clap/blob/main/include/clap/ext/gui.h ... there you can read how the pointer can be handed to the plugin)

maybe obvious but interesting in this context: by itself, clap is pure c, so does not depend on the standard library or anything else