Open JohannesLorenz opened 4 years ago
This sounds like a good idea to me, but downside 3 is my biggest concern. Can you elaborate on how exactly this makes things harder?
Since we should still have access to all the saved effect parameters(?), I assume the issue is that we no longer control which version of the plugin is installed. Is it fair to say "upgrade the plugin bundles at your own risk"? Technically it's not our bug if a user upgrades a plugin and the output is different, right?
Can you elaborate on how exactly this makes things harder?
I think you already mentioned my concern :+1: And I also think your "upgrade the plugin bundles at your own risk" statement makes sense. An issue is though that if you just tell your system "update all packages", this can update e.g. the calf lv2 packages without that you really wanted that.
The overhead to track the version of the lv2 plugins (if that's even possible) and then change our ports when they change their code sounds too large to me.
More opinions?
Why not going into fully native? I know, there wasn't every plugin yet, but current (master + PR's) were decent ones, and cover majority of what is needed by casual user.
I think this is not good idea. We can think about porting LADSPA to LMMS format with better GUI but with compatibility:
P.S.
LADSPA is fine for effects except GUI - it is complicated for understanding (especially for beginners).
There still need to be support for old LADSPA, and there still need to be a LADSPA library similar to 1.2.2 available, either as separate download (preferred) or included (bloating downloads/ Server usage) Upside not mentioned is that one of the strangest components in lmms can be shelved! I am ofcause talking about the "Ladspa-plugin-browser".
Enhancement Summary
The summary says it all. Use the system-installed lv2 libs instead of providing LADSPA in our submodules.
Justification
This will:
I'm not sure if this will work, though. A few points:
Opinions?