Forums
Absolute paths can present privacy and security problems if sessions are shared. While the risk is very low, it depends heavily on the user's chosen username and how much information that username reveals. Perhaps it's a negligible risk, but it's easy to avoid...
I know this doesn't affect lv2, but it does affect other formats.
re. Relative paths for plugins in session documents...
what do you suggest (relative paths) is prolly no better than what it's now (absolute paths)...
consider that some if not most plugins are installed on the system paths (eg. /usr/lib* or /usr/local/lib*) what exactly would be their relative paths? ../.../usr/lib* or ../.../usr/local/lib* ? isn't that the same but only with more ../.. gibberish?
my 2cents.
Re: Plugins are installed on system paths
That's not true. Distributing plugins via installers is an outdated practice.
Users need control over where and how they organize their plugins. Control over whether or not they want to update.
How many of these are distributed as installers?
https://linuxdaw.org/?p=f&l=o
No one with experience in Linux audio installs plugins from the OS repositories.
They're outdated.
They've suffered from the problems that come with it. The system decides to change library paths, and suddenly, you don't know where the plugins are. Administrative privileges make it difficult to solve the problem if you're not an experienced user (there have been issues with this in this very forum). Making backups becomes an unmanageable nightmare.
You don't want to deal with pre-installed plugins you'll never use, which make it difficult to find the ones you will (as is the case with themed Linux distributions for audio and multimedia).
They stopped working due to the abandonment of GTK2.
Installing plugins in the system directory is pointless because they aren't application dependency libraries; they're user utilities. The only justifiable case is if the plugin is truly an essential dependency for a program to perform a specific function (for example, GMsynth lv2, which includes Ardour by default).
But if you go to the developer's website, they distribute it as a zip file.
https://x42-plugins.com/x42/x42-gmsynth
True, the paths to plugins installed in the administrative directory would be a jumble of dots and slashes, but they would work. Although, really, what musician installs their plugins there anymore? We all do it locally, for the reasons explained.
I've even managed to get Calf running locally and working.
My 4 cents (2 yours and 2 mine) :) I'm not trying to start an argument, just letting you know that it's a reality these days.
Can't agree
I compile the plugins on my machines (no more glibc symbol not found) and install them in /usr/local/lib/ladspa, lv2, vst, vst3 or clap
That's default for most of the plugins' build systems.
The disadvantage of relative paths would be that the plugins are not found if the song directory goes one level up or down.
But there's another solution:
How about stripping the plugins' path completely, only leaving the filename in the session file? Qtractor would load them via the configured plugin paths.
Instead of
<filename>/usr/lib/ladspa/amp.so</filename>
we'd use
<filename>amp.so</filename>
re. stripping the plugins' path completely...
that would be the sane(st) solution, thank you!
however let's put it in an dang experimental branch targeting for v1.6.0, shall we? ;)
cheers
yes, I'd test it
with my existing projects as a backwards compatibility test.
But:
Sessions that are saved with this new Qtractor version cannot be loaded with older Qtractor versions if there are plugins that needed a full path. No big problem I think.
Add new comment