LV2 vs CLAP

[tramp]

I'm sure this could be better taken to another thread if you want to discuss it... My original response to @raboof was already offtopic enough and this is an important discussion on it's own..

I don't want to discuss it, but I want to respond to your indeed offtopic response, cause I think it takes to much grain of salt to leave it as it is. So, a view from a other side hopefully put some sugar about it.

[tramp]

And while we are one it, and to make a bridge from the MOD to back to topic, that is one of the drawbacks I see for Clap versus LV2. With Clap, a unit like MOD wouldn't be possible, because Clap didn't separate dsp and UI callbacks. So a remote Web based control interface wouldn't be possible.

[GMaq]

What a company does with it's input sources and what it provides to it's customers have no direct correlation... You receiving justly deserved money and products for your hard work and product is a company expense... MOD can pay you with their own money thanks, not mine!

What I said is neither salt or sugar, it's an observable event... however to say I (and the many other MOD backers) have been 'ghosted' was hyperbole quoting from what raboof said so I give you that... MOD has not yet delivered on it's promise but it hasn't (yet) abandoned the backers... 6 years is an unforgivably long time though...

I'm out!

[tramp]

MOD can pay you with their own money thanks, not mine!

Thanks @GMaq for your support of my work for the open source community.

[Basslint]

[...] Clap didn't separate dsp and UI callbacks. [...]

Isn't this a very serious drawback or am I understanding it badly? Why did they make this choice?

[robbert-vdh]

[...] Clap didn't separate dsp and UI callbacks. [...]

Isn't this a very serious drawback or am I understanding it badly? Why did they make this choice?

While DSP/UI separation is a good thing in theory, having it be a mandatory requirement to use a plugin API makes plugins more complicated and involved to implement. And if it's encouraged but optional, like it is in VST3 (just implement IComponent and IEditController on a single object) or LV2 (instance access), you tend to end up with the worst of both worlds. I don't think this goes as much for LV2 as it does for VST3, but VST3 became a lot more complicated than it otherwise would have needed to be as a result of the DSP/UI separation. And to get back to the first point, while on paper this does sound like a useful feature for a plugin API, in practice it's only useful in a handful of situations. From the top of my head, the most important ones here are:

1. Platforms like the MOD.
2. For plugin APIs with static manifests that define all of the plugin's parameters and that include and enforce API-defined ways to communicate between the UI and DSP part of the plugin, the separation allows for Interchangable UIs. This sounds nice, but it's only possible when the API enforces a certain programming model like LV2 does, which in turn makes things more complicated again. For APIs that don't have static parameter manifests, you're mostly left with point 1. Which in my opinion is niche enough that it would warrant its own API or API extensions to make better use of the platform.

Instead of enforcing the plugin to do DSP/UI separation in a very specific, implementation defined manner (which again, won't fit most plugins, so they'll try to find ways around it which ends up making things worse for everyone), my idea for supporting platforms similar to the MOD with CLAP would be to simply define a non-parameter state synchronization API. Parameters can already be trivially synchronized between two plugin instances because CLAP has a single stream for all input and output events going to and from the plugin. So if you'd load the plugin on two devices, call just the process function on one and load just the GUI extension (or another UI extension that suits the platform better) on the other, synchronize the parameters using the process and flush functions, and then use a bespoke non-parameter state synchronisation extension that allows the plugin to provide a void pointer and a byte size to the host which then copies the data and provides it as is to the other side, you would get all the features you need for integration with MOD-like platforms without having to complicate the base API.

[nils]

This thread:

[tramp]

Instead of enforcing the plugin to do DSP/UI separation in a very specific, implementation defined manner (which again, won't fit most plugins, so they'll try to find ways around it which ends up making things worse for everyone),

Well, that was true for LV2 before we got atom ports. With atom ports there is no need any-more to do anything with instance access.

To support a platform like the MOD, you must be able to build the plugin without the need of a GUI frame work library, that, is only possible when you could build the plugin headless.
I'm not deep diving into Clap (for now), but my impression is, that Clap plugs been build with the GUI framework implemented deep into the plugin itself, so, you can't build them headless. Am I wrong here?
While a a non-parameter state synchronization API sounds nice (that's what we use for internal guitarix plugins, register var, give it a id, and modify it then from everywhere. No matter if modification comes from host, from UI or from dsp, always in sync ), we need a option to build the plugin without the GUI at all. Only that will allow to really separate the UI <=> dsp interaction via the host.

[robbert-vdh]

Well, that was true for LV2 before we got atom ports. With atom ports there is no need any-more to do anything with instance access.

And the reality is, most plugin developers don't want to restructure their plugin (and probably, redesign their existing internal plugin framework) just because a plugin API demands is. Take VST3 for example. FabFilter is quite literally the only commercial plugin developer I know of that implements VST3's DSP/UI separation. All other developers either don't do it at all or they pretend to do it but then awkwardly sidestep it by exchanging object pointers using the messaging system.

To support a platform like the MOD, you must be able to build the plugin without the need of a GUI frame work library, that, is only possible when you could build the plugin headless.
I'm not deep diving into Clap (for now), but my impression is, that Clap plugs been build with the GUI framework implemented deep into the plugin itself, so, you can't build them headless. Am I wrong here?
While a a non-parameter state synchronization API sounds nice (that's what we use for internal guitarix plugins, register var, give it a id, and modify it then from everywhere. No matter if modification comes from host, from UI or from dsp, always in sync ), we need a option to build the plugin without the GUI at all. Only that will allow to really separate the UI <=> dsp interaction via the host.

CLAP does not make any assumptions about what your plugin is or what it can do. Everything is an extension. In fact, if you only want to process MIDI, you'd just not implement the audio-ports extension at all because you don't need it. Similarly, GUIs are also just an extension. And if a platform (like the MOD) would benefit more from a HTML view than a regular desktop GUI, the best way to go about that would probably be to just define a new web-gui extension. I'm sure that would actually also be useful for some other hosts like Angklang, so having something like that in the CLAP repo wouldn't sound unreasonable.

[tramp]

CLAP does not make any assumptions about what your plugin is or what it can do. Everything is an extension. In fact, if you only want to process MIDI, you'd just not implement the audio-ports extension at all because you don't need it. Similarly, GUIs are also just an extension. And if a platform (like the MOD) would benefit more from a HTML view than a regular desktop GUI, the best way to go about that would probably be to just define a new web-gui extension. I'm sure that would actually also be useful for some other hosts like Angklang, so having something like that in the CLAP repo wouldn't sound unreasonable.

Most LV2 plugins which are used on the MOD wasn't developed special for the MOD. But because the dsp and the UI part been separated it was a easy task to port them to the MOD. A little patch for the makefile and a new UI for the MOD. Very easy to do.
So, a new web-gui extension wouldn't help here to port clap plugins to the MOD, as the UI and the dsp part been clued together in one source/binary. To use them on the MOD, the clue must be removed, which may be a lot of work.
A web-gui extension will only help to write new plugins special for the MOD, but not to reuse existing ( or further written) ones.

[Kott]

So, a new web-gui extension wouldn't help here to port clap plugins to the MOD, as the UI and the dsp part been clued together in one source/binary. To use them on the MOD, the clue must be removed, which may be a lot of work.
A web-gui extension will only help to write new plugins special for the MOD, but not to reuse existing ( or further written) ones.

Why not to compile in headless mode and add the web extension?

PS if a headless is an option

[scott.thomason]

[...] Clap didn't separate dsp and UI callbacks. [...]

Isn't this a very serious drawback or am I understanding it badly? Why did they make this choice?

While DSP/UI separation is a good thing in theory, having it be a mandatory requirement to use a plugin API makes plugins more complicated and involved to implement.

Full disclosure: I've never written an audio plugin, but I am a career-long programmer in other fields who has great interest in this programming topic and the quality of programming in general. With that out of the way...

I have to say having the framework explicitly separate the UI from the DSP sounds like an awfully good thing. Being able to _reliably_ have collections of headless DSPs would inspire all kinds of collaborations and compositions, such as a web interface that conglomeratively(new word) manages multiple DSPs with one UI, combining parameter interactions together in ways the original DSP developers couldn't have anticipated.

In fact, there's no reason at all that an audio plugin standard should have to support the GUI aspect at all...there are already many good GUI builders that could be used to interact with DSPs. Let the hosts provide either provide their own GUI implementation, or let the community develop an audio host UI standard independently if a per-host implementation is too burdensome. The main point being that separation of concerns is good, and that topic has been discussed and documented thoroughly over the decades to the point where it is scarcely debatable.

[scott.thomason]

...scarcely debatable.

LOL...I forgot which forum I was posting this at. Let the debate begin.

[robbert-vdh]

I have to say having the framework explicitly separate the UI from the DSP sounds like an awfully good thing.

A plugin API is something completely different from a plugin framework. Your plugin framework may support multiple plugin APIs, and enforce a DSP/UI separation independently of whether the targeted plugin APIs have the same requirement. Having it be a hard requirement for a plugin API just means that only a handful of plugin developers will buy into the API. People don't want to have to completely redesign all of their tooling and frameworks to accommodate plugin APIs that only support certain limited workflows. Like I said, DSP/UI separation is a good thing. Forced DSP/UI separation when there is no reason for it to be forced is not. That only makes the API more cumbersome to use, because now you need to do things in a certain way that that make binding to the API more difficult or straight up impossible (depending on how enforced it actually is).

In fact, there's no reason at all that an audio plugin standard should have to support the GUI aspect at all...there are already many good GUI builders that could be used to interact with DSPs.

Good luck using plugins like Melodyne or B.Shapr without a GUI. Not all of a plugin's state can be captured through parameters. How would Vital's or Serum's wavetable editor work if the plugin didn't have a GUI?

[wrl]

I have to say having the framework explicitly separate the UI from the DSP sounds like an awfully good thing. Being able to _reliably_ have collections of headless DSPs would inspire all kinds of collaborations and compositions, such as a web interface that conglomeratively(new word) manages multiple DSPs with one UI, combining parameter interactions together in ways the original DSP developers couldn't have anticipated.

This is still possible even with plugins that have GUIs. Automation parameters are still exposed and available.

In fact, there's no reason at all that an audio plugin standard should have to support the GUI aspect at all...there are already many good GUI builders that could be used to interact with DSPs. Let the hosts provide either provide their own GUI implementation, or let the community develop an audio host UI standard independently if a per-host implementation is too burdensome. The main point being that separation of concerns is good, and that topic has been discussed and documented thoroughly over the decades to the point where it is scarcely debatable.

With a few small exceptions, plugin APIs basically only provide facilities for plugins opening OS-level windows, the plugins therafter doing all of their eventing and drawing themselves. I have a dim recollection of early plugin APIs (VST1, I think? maybe early versions of VST2) supporting more involved event dispatching to the plugin window (and perhaps providing a framebuffer? don't remember, wasn't there.) but the ecosystem as a whole has moved on from that.

-w