The reason will be remote control. And, while IT development moving forward, remote control becomes more and more significant (wasm). So, push out a new standard which ignore this requirements is, sorry, not a good thing. I guess I don't need to include the good old comic about evolving standards here.robbert-vdh wrote: ↑Fri Jul 08, 2022 3:18 pm 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.
robbert-vdh wrote: ↑Fri Jul 08, 2022 3:18 pm 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).
What? I cant see a difference here. A API is a API. I've to read and follow to get things done. It is not more difficult to follow a API which provide dsp/UI separation then follow one which don't force that. It's always the same. read, learn, follow. So, why do you think the API of Clap is easier to follow then the one of LV2? It's just a question of mindset.
Again, a trap you stepped in. It's not about headless plugins, it's about remote control. And, there wont be a single issue providing a remote control for B.Shapr, as it use atom ports instead instance access so all controls could be done from a third party window (given it knows what it does).robbert-vdh wrote: ↑Fri Jul 08, 2022 3:18 pm 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?
(PS:) but now that I've learned that open source developers may get paid when they implement Clap support, I may change my mind and revert all I said above.
https://www.kvraudio.com/forum/viewtopic.php?t=574861