CLAP: headless, DSP-less, and combinations? Are the UI and DSP decoupled?

[amyodov]

Hello!

This is for now a question; but if the answer is no, this should be definitely treated as "idea"!

I have high hopes about the overall CLAP development, but my hottest question is, well, a pack of related questions:

1. Does CLAP architecture support running plugins in completely headless (DSP-only) way? In such a way, that the CLAP host would tell the plugin (well, to only it's DSP code) "don't even try to display anything, there is no display here, well, don't even bother linking UI libraries" and run the whole plugin completely remote-controlled?
2. On the opposite, does CLAP architecture support running plugin in completely DSP-less, UI-only form? The host would tell the plugin “just draw your usual UI and give me its values/etc, don't bother handling audio itself”?
3. And, linking all of that: does CLAP architecture support host-side configuring/binding the UIs with the appropriate DSPs?

If yes, then what headers/parts of the CLAP specification I should pay the most attention? If no, then why :) ?

Well, I'm obviously speaking about the workflows like dedicated DSP hardware, Universal Audio UADs (just not audio->audio only, but, in case of CLAP, midi->audio, etc. Think Diva and Hive running on a “DSP accelerator”. Think Audiogridder/Vienna Ensemble Pro, but with the architectural support from the standard. Think Astrolab-like keyboard that runs CLAP plugins of your choice, enhancing them with CLAP effects of your choice (and, if its builtin CPU performance becomes insufficient, you can just plug in the “DSP accelerator” from two sentenced before).

[baconpaul]

1. yes you could easily write a host which did this and i have thought of doing exactly this in the clap-wrapper project as a cli-standalone
2. a bit less yes. You could write a host which does this and well behaved claps should work, but some may rely on the audio loop for some items. So 'yes in spec' but 'defacto i don't know a host which does this'
3. yes you can easily write a generic host ui. the api allows full discovery of all params, features, etc and none of that relies on the gui extension.

the way i've thought about doing headless clap is have the clap wrapper project have another ejected format which is a standalone executable. This would be roughly equivalent to what we did with surge-xt-cli.