search

flathub / org.freedesktop.LinuxAudio.BaseExtension

https://flathub.org/apps/details/org.freedesktop.LinuxAudio.BaseExtension
8 stars 2 forks source link

[Proposal] [22.08] Rename lxvst to vst #10

Closed Bleuzen closed 3 years ago

Bleuzen commented 3 years ago

From https://github.com/flathub/studio.kx.carla/issues/2

Seems that only Ardour uses the name lxvst while usually vst is more common. The latter name also makes more sense, since it is not os specific and usually user installed vst2 plugins are also in a directory called ~/.vst.

For this to work, we would have to change the

"VST_PATH=/app/extensions/Plugins/lxvst"

to

"VST_PATH=/app/extensions/Plugins/vst"

in these apps (report if missing):

And also build all the plugins into the new path, see: https://github.com/flathub?q=LinuxAudio.Plugins https://github.com/search?q=org%3Aflathub+lxvst&type=code

hfiguiere commented 3 years ago

it's not user visible. it doesn't matter. there are more important things to do.

falkTX commented 3 years ago

Of course it does matter, and it is user visible. Just as an example, I do not have a ~/.lxvst but have a ~/.vst.

A good base is always essential for building things on top. I am a bit surprised by the outright dismissal here, please re-open and let's discuss this.

hfiguiere commented 3 years ago

~/.lxvst is NEVER even referenced here.

falkTX commented 3 years ago

lxvst will be shown to the user though, and the user will want to use their own local plugins. If I see $prefix/lib/lxvst on a path, I assume it is wrong and a bug. I am likely not alone in this, as this "lx" name scheme does not match any other plugin format.

The mismatch of "vst" and "lxvst" will cause issues down the line.

Bleuzen commented 3 years ago

@falkTX

[...] and it is user visible.

It is only user visible to users who manually open the settings of for example Carla and have a look at the configured path. But who really does this? Never had to do this myself yet and I guess most users won't and don't care what name is in their path, as long as all the plugins show up.

[...] and the user will want to use their own local plugins.

only because we use lxvst in the system path does not mean we also have to use it for the user path. For example we can set it like this: --env=VST_PATH=/home/user/.vst:/app/extensions/Plugins/lxvst

which won't require a change in the BaseExtension and change and rebuild of all plugins.

If I see $prefix/lib/lxvst on a path, I assume it is wrong and a bug.

I see the point, but let's not forget that we are developers/packagers.
Normal users will most likely install the software from a GUI app, launch it and just use it as is and never care about what those "under the hood" variables are, if they even know they exist.

I am likely not alone in this, as this "lx" name scheme does not match any other plugin format.

True, I also don't like it. But also, as of my current knowledge, it seems only cosmetic and most users won't see it. So if no other good reason to change comes up, I can understand @hfiguiere here:

there are more important things to do.

@falkTX

The mismatch of "vst" and "lxvst" will cause issues down the line.

Can you explain which ones there could be?

falkTX commented 3 years ago

It is only user visible to users who manually open the settings of for example Carla and have a look at the configured path. But who really does this? Never had to do this myself yet and I guess most users won't and don't care what name is in their path, as long as all the plugins show up.

Please do not speak for other users. Since it is seems that the wish is for ~/.vst like paths to not be enabled by default, users will want to go into the paths and configure it. I mentioned before that I have some vst2 plugins in that folder, certainly I am not alone since stuff like u-he installer script puts files in that location as well.

only because we use lxvst in the system path does not mean we also have to use it for the user path. For example we can set it like this: --env=VST_PATH=/home/user/.vst:/app/extensions/Plugins/lxvst

which won't require a change in the BaseExtension and change and rebuild of all plugins.

True, but the the mismatch is confusing at best. I am not saying to change it now, but it should be changed to be consistent. And it is better to define this now rather than later.

The mismatch of "vst" and "lxvst" will cause issues down the line.

Can you explain which ones there could be?

Future-proofing basically.

But if you really need use-cases / potential issues:

  1. the obvious is that "vst" vs "lxvst" is inconsistent
  2. someone searching for why a certain plugin does not work (it is fairly common, specially with commercial plugins) will for sure end up seeing the odd-looking "lxvst" path and assume some kind of error
  3. once vst3 gets more popular, people will refer to it when saying "vst" (as vst2 becomes less and less popular)

IMO even $prefix/lib/vst is wrong now, only kept for legacy reasons. New systems where possible should use $prefix/lib/vst2

As I see it here, there is purely a clash between "let's keep things as-is and not do extra effort" vs "let's do things proper since it is still early". Besides avoiding a little work, I don't see any technical limitations for not going with "vst" or preferably even "vst2" instead of "lxvst". Working for the short-term goals and profits is how corporations plan things, I hope we see things differently here and plan for the long-term. Thanks.

robbert-vdh commented 2 years ago

I wanted to pitch in that I agree that */lxvst should indeed be */vst. LXVST is not a thing. Ardour is the only program that uses the term, and I've actually seen the use of this term cause confusion for users. If changing this would result in momentary breakage, then allowing both during a grace period would be a good solution.

abique commented 2 years ago

I'd +1 for using vst instead of lxvst.

Even if the end user don't face it, when daw and plugin vendors will start to package their tool, they'll have the feeling that the foundation is not solid.

The longer we wait, the more difficult the change will be. This topic may periodically come back.

pauldavisthefirst commented 2 years ago

Ardour's use of "lxvst" originated at a time when we supported a build process that created a windows executable that could load windows VST plugin (using FST) and linux VST plugins (natively). It did not seem appropriate to pretend that a user should keep plugins from each platform in the same location.

We have removed support for that build recently, and we can (probably) drop the "lxvst" term before we release v7.