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.
LV2 vs CLAP
Moderators: MattKingUSA, khz
-
- Established Member
- Posts: 2348
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 468 times
Re: LV2 vs CLAP
On the road again.
-
- Established Member
- Posts: 2348
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 468 times
Re: LV2 vs CLAP
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.
On the road again.
- GMaq
- Established Member
- Posts: 2831
- Joined: Fri Sep 25, 2009 1:42 pm
- Has thanked: 530 times
- Been thanked: 576 times
Re: LV2 vs CLAP
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!
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!
-
- Established Member
- Posts: 2348
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 468 times
Re: LV2 vs CLAP
Thanks @GMaq for your support of my work for the open source community.
On the road again.
-
- Established Member
- Posts: 1516
- Joined: Sun Jan 27, 2019 2:25 pm
- Location: Italy
- Has thanked: 385 times
- Been thanked: 299 times
Re: LV2 vs CLAP
Isn't this a very serious drawback or am I understanding it badly? Why did they make this choice?
The community of believers was of one heart and mind, and no one claimed that any of his possessions was his own, but they had everything in common. [Acts 4:32]
Please donate time (even bug reports) or money to libre software
Jam on openSUSE + GeekosDAW!
Please donate time (even bug reports) or money to libre software
Jam on openSUSE + GeekosDAW!
-
- Established Member
- Posts: 219
- Joined: Mon Mar 01, 2021 10:56 pm
- Has thanked: 51 times
- Been thanked: 92 times
- Contact:
Re: LV2 vs CLAP
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:
- Platforms like the MOD.
- 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.
-
- Established Member
- Posts: 2348
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 468 times
Re: LV2 vs CLAP
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.robbert-vdh wrote: ↑Thu Jul 07, 2022 5:31 pm 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),
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.
On the road again.
-
- Established Member
- Posts: 219
- Joined: Mon Mar 01, 2021 10:56 pm
- Has thanked: 51 times
- Been thanked: 92 times
- Contact:
Re: LV2 vs CLAP
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.
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 wrote: ↑Thu Jul 07, 2022 6:08 pm 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.
-
- Established Member
- Posts: 2348
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 468 times
Re: LV2 vs CLAP
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.robbert-vdh wrote: ↑Thu Jul 07, 2022 6:45 pm 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.
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.
On the road again.
-
- Established Member
- Posts: 821
- Joined: Thu Mar 21, 2013 12:55 am
- Location: Vladivostok
- Has thanked: 65 times
- Been thanked: 124 times
Re: LV2 vs CLAP
Why not to compile in headless mode and add the web extension?tramp wrote: ↑Fri Jul 08, 2022 6:25 am 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.
PS if a headless is an option
- scott.thomason
- Established Member
- Posts: 120
- Joined: Fri Apr 01, 2022 2:54 am
- Has thanked: 16 times
- Been thanked: 27 times
- Contact:
Re: LV2 vs CLAP
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...robbert-vdh wrote: ↑Thu Jul 07, 2022 5:31 pmWhile 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.
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
- Established Member
- Posts: 120
- Joined: Fri Apr 01, 2022 2:54 am
- Has thanked: 16 times
- Been thanked: 27 times
- Contact:
-
- Established Member
- Posts: 219
- Joined: Mon Mar 01, 2021 10:56 pm
- Has thanked: 51 times
- Been thanked: 92 times
- Contact:
Re: LV2 vs CLAP
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).scott.thomason wrote: ↑Fri Jul 08, 2022 2:50 pm I have to say having the framework explicitly separate the UI from the DSP sounds like an awfully good thing.
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?scott.thomason wrote: ↑Fri Jul 08, 2022 2:50 pm 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.
Re: LV2 vs CLAP
This is still possible even with plugins that have GUIs. Automation parameters are still exposed and available.scott.thomason wrote: ↑Fri Jul 08, 2022 2:50 pm 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.
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.scott.thomason wrote: ↑Fri Jul 08, 2022 2:50 pm 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.
-w