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.
we'll see...
in the next year anyway
cheers
Thanks to both of you!
There shouldn't be a problem. As long as the path is correctly configured in the options and the plugin is present, Qtractor loads it correctly, regardless of the path in the session. It's always been this way.
I know the problem I'm describing is silly, but this way you don't have to keep cleaning up files if you want to share them. More than a real risk, it's because it doesn't look clean in a session document, which is, for example, a template, an exercise, or a demo... since your user paths appear there.
branch [xpluginpath]
it's there now xpluginpath...
the proverbial caveat emptor applies... sessions saved with this feature won't get some if not all plugins loaded if running on regular main/develop binaries; however some will, iif based or located at the top of one of the search paths (cf. View/Options.../Plugins/Paths).
forget all hope if you now have duplicate or several plugins for testing--only the first found on the search list will come up.
you've been warned ;)
cheers
re: branch [xpluginpath]
Works ok so far. Mixed session with LV2 and LADSPA plugins. Path of the LADSPA plugins was removed when saving the session. Session is loaded properly.
re. branch [xpluginpath]
It works, however, I ask that you reconsider my initial request.
It has some collateral advantages.
It doesn't have the problem of not being able to have different versions of the same plugin.
It facilitates portability. Except for two exceptions: LV2 and plugins that have dependencies (samples, text files, images).
Let's imagine some scenarios:
A. I want to use another computer occasionally. I only need to take the USB drive with a Qtractor AppImage and my projects and plugins in the same hierarchy as on my personal computer. Everything will open without having to configure anything on the destination computer.
B. I'm going to a friend's house, who is also a musician. Here, the advantage of not having to modify their destination configuration is more significant.
C. A music academy prepares the course materials on USB drives for students, with pre-configured plugins and exercises (in this case, LV2 and plugins with dependencies are not a problem, since the content is specific and would be avoided when including them in the exercises). Furthermore, this way students don't have to scan and install plugins, which, although useful for their training, might not be suitable for their personal work.
Etc.
EXCEPTIONS:
The problem with LV2 is solved by reconfiguring the scan path in the destination... It's an inconvenience, but at least it's not six inconveniences (LV2, LADSPA, CLAP, DSSI, VST2, VST3).
Regarding the problem with plugins with dependencies, the only solution is to avoid them as much as possible.
CONCLUSION:
Advantages: The initial request provides a new improvement in functionality, not complete due to the exceptions mentioned, but an improvement nonetheless: Portability.
Drawbacks:
Sometimes we'll find unpleasant and lengthy strings of slashes and periods within the session files.
I'm simply asking you to weigh the pros and cons.
Whatever you decide, I'll be happy.
re. maybe considered in...
[xpluginpath 69dc1ae5a] (forced update)
please test && tell
thanks
re. re. maybe considered in...
The problem is that it doesn't save the relative path, but rather the name. Therefore, the relative path it will always read will be the project directory, since that's equivalent to no path at all (only the name).
From the beginning, if you provided Qtractor with a valid path to the plugin (whether relative or absolute), Qtractor's first action is to load it. And if the "not found" warning doesn't appear. (I think it's in the session file)
It is unnecessary checks if it exists or not in the configuration paths... because if it's there, it's because it exists, regardless of where... whether within the paths defined in the configuration or in the paths defined by the session paths.
This seems to work, although I'm not sure if the last "return false" is necessary. As you say // Might never reach here! :)
// Check/sanitize plugin file-path to save (absolute->relative)... bool qtractorPlugin::savePluginFilename ( QString& sFilename, qtractorPluginType::Hint typeHint ) const { // Care of internal pseudo-plugins... if (sFilename.isEmpty()) return false; // LV2 plug-ins are identified by URI... if (typeHint == qtractorPluginType::Lv2) return true; // Force plugin relative path... qtractorSession *pSession = qtractorSession::getInstance(); if (pSession) { sFilename = pSession->relativeFilePath(sFilename); return true; } // Might never reach here!... return false; }re. maybe unconsider...
sorry to tell, this last change is in fact entirely moot or of no consequence in practice... I'm even considering to revert it shortly...
the stance is: what seems to work for you, having general relative paths based on ../... and so on, is not acceptable for plugins, sorry again.
the rule is: plugins must always be found under one of the configured plugins search paths, not anywhere else.
that's the rule to follow if you want no absolute paths in session files.
taking back my 2c. :)
hyu.
ps. reverted, [xpluginpath 498cf555f] is the new tip; you'll need to
git reset --hard origin/xpluginpathafter this.:) I can only express my gratitude for the effort
As I said, that seems right to me. I'm missing a lot of things (I'm tinkering with fluidsynth-dssi to achieve the same thing with its SF2, and there were explicit comments in the code about not using relative paths, or at least that's what I understood; my English isn't very good).
Thanks for going beyond simply considering it, even though the final conclusion was no.
What about "."
If the dot would have a special meaning (= the session directory) everyone could tell Qtractor to look for plugins in the session directory by adding . as a plugin search path.
re. What about "." ...
nope.
it breaks the rule (see my earlier comment), unless the session directory is one of the configured plugin search paths (unlikely but possible at user discretion).
br.
It seems to work well
It solves the privacy problem, which is what I originally requested.
If we want multiple versions of the same plugin, we simply need to rename the binary file, for example, CoolPlugin.v1.so, CoolPlugin.v2.so. In the case of LV2, it can also be achieved by editing the URI in the C file before compiling; it's more cumbersome, but possible.
I've learned a lot from this last request.
Thank you very much for solving it, and I intend not to ask for any more features. (I think I've been the most persistent by far XD).
(And speaking of persistent, this is going to be a long-winded explanation, so you can completely ignore it).
I've finally understood that the dependency (and therefore portability) problem is unsolvable as current operating systems are configured. There are partial solutions, and one of them is for hosts to at least keep track of what should be there and notify you if something is missing. (fluidsynth-dssi not only loads sf2, it is also an sf2 host, hence the warning I read in the code about that host rule I was unaware of)
But I've also arrived at a theoretical solution. In addition to the structure based on a category taxonomy (directories), there should be one based on a tag taxonomy to allow multiple relationships and unique element identifications.
Symbolic links are an approach, but they aren't sufficient (as experience shows).
Tag taxonomy has been successful for media management applications. The entire operating system should have incorporated this media management capability long ago.
(When did UNIX emerge? What has changed?).
As long as two IDs are related, it doesn't matter where they are located.
It has also been successful for content management systems like Drupal, or for graphic formatting languages like CSS, where classes are not really classes in the style of programming languages, but rather tags.
Some programming languages support multiple inheritance classes; it's very similar but not exactly the same concept. In multiple inheritance, there is a predefined hierarchy and dependency. However, tags can suggest descendant and ascendant relationships based on context, but they are not predefined. If the ascendant disappears, the descendant retains its identity.
This would also solve the problem of library dependencies... and unsatisfactory solutions like AppImage or Flatpak would no longer be necessary.
Finally, the operating system would be truly free, because it would no longer be bound by hierarchies, but rather driven by fluid relationships (tags), and because the elements would occupy a localized space (directories). However, in nature, space is one of the means of establishing relationships, but it is not a relationship in itself... and from establishing this false equivalence of location = relationship, all these problems arise.
Thank you for everything.
Add new comment