This time it is a functionality that I need to be able to have the plugins organized to my liking.
Now I have an incomprehensible problem when compiling.
"cmake -B build" tells me:
LV2 plug-in support. . . . . . . . . . . . . . .: No
All libraries are installed (the same ones from the last successful build I did).
I have reinstalled them to make sure.
CMakeLists.txt defaults to "lv2" support.
Linux things.
However, there is no problem, it is a functionality that I need, but it is not urgent.
I will continue using the default .lv2 folder for presets until the new version of Qtractor is released.
I don't like that it's a hidden folder.
I also prefer to be able to have these files under my own directory structure logic for the sake of simplifying possible backups.
But it's not something urgent.
I wanted to compile your arrangement to test, and above all to use, because I needed it (although not urgently).
I don't know why I didn't get compile. (Linux mysteries)
Then I realized that I could edit Qtractor.conf directly, and I shared the variable in case someone else wanted to configure it that way (without having to recompile Qtractor).
--- Info extra---
"what's this really about?"
There really is an underlying issue. I share it because it is something that I really think needs to be commented on, but of course I am not forcing anyone to read it.
It has nothing to do directly with Qtractor, but Qtractor is affected.
_We have a problem, and it is UNIX mode_
The hierarchical organization of Unix files is a great absurdity, and that causes problems.
I have already commented on these types of problems before in this forum (problems when sharing plugins, problems when creating your own file organization for a custom workflow...).
I knew those problems were there, but I didn't know the origin, I finally realized: UNIX mode.
Dismember the app identity into "bin", "etc", ".config", "share" is not functional.
And worse, it leaves "shared" resources out of reach of the user under administrative permissions. That "share" requires administrative permissions is a paradox in concept.
It makes it difficult and even prevents the user from locating and establishing their own organization.
Due to this nonsense, some programmers choose to save the resources of their programs in the user path in hidden!!! folders, others in the personal documents folder, others in the local .var, o .local or .config folders... Total chaos. (hidden!!!: Hiding doesn't help either.)
There are some initiatives that try to provide a solution:
- Appimages: Hiding the app's resources in a Zip doesn't seem like a solution to me.
- HelloSystem: A FreeBSD distro from the same author of Appimages that recreates Apple's System7 experience. I think it (like System7 and MacOX) have the same problem as Appimages. https://hellosystem.github.io/docs/
- GoboLinux: I think it is a successful proposal, but it is still far from being friendly. https://gobolinux.org/
(It is curious that perhaps Windows is the one that has the most accurate and free file organization.
Programs maintain an identity with their resources, their configurations, and are traceable.
User programs are differentiated from system applications.
Installable with a graphical interface that allows you to decide where to install, without conflicting with anything...)
_It's not a complaint, it's just a statement of a problem_
I can't create a Linux distribution that solves all this, I lack knowledge and resources.
I would be at the same point as GoboLinux, I would have to create installables (in my case with a Windows-style graphical interface) for the thousands of existing programs and maintain them. That is a task that requires many people.
What I can do is try to find solutions so that my user's file structure is the least dependent and most free. Also share my progress.
I can also report the problem, because until recently I was aware of its consequences, but not its origin.
Being aware of the root problem is the only way to find true solutions, and not patches.
We have a problem, and it is UNIX mode.
and then you're beating on a dead horse... :) all that has been addressed by the freedesktop.org standards and recommendations already, and for quite some time...
take a note: Unix and Linux is not Windows, you certainly know that; windows is, in its loose file-system hierarchy model, if one may call it that way, and I bet young people might not remember, just because they're weren't born at the time, is just a PC/MS-DOS crappy disk/file model on steroids.
for quite some time, the Unix FHS is, yeah, The Standard, and it will probably prevail over the test of time: the windows/msdos crap will fade out to oblivion, give or take a century or two XD
I am glad that we can present them in this forum, because Qtractor is closely linked and conditioned to its ecosystem.
I could continue arguing why UNIX mode is a problem, but it makes no sense. For those whose UNIX mode does not generate conflicts, everything is fine.
For those who are not comfortable with UNIX mode (I'm not the only one, GoboLinux is proof of this), there is solutions, and it is precisely in the user folder.
I'm still working out my workflow. When I manage to solve it and test it for a few months I will share it.
"Symbolic links" are the standard way to customize paths in Linux.
Being standard, they are reliable (It didn't take me months of testing as I thought.).
I have been an exclusively Linux user for more than 15 years.
However, I was unaware that the main functionality of symbolic links was to customize paths.
If there is another clueless person out there like me, the following example may be of help.
Example in the case at hand:
I want to customize ".lv2" not only for Qtractor, but for the entire system locally.
Steps:
1 I move /home/Iam/.lv2 to /home/Iam/path/I/want/.lv2
2 I rename .lv2 to lv2 so that it is not hidden
3 I create a symbolic link of /home/Iam/path/I/want/lv2 to /home/Iam/.lv2
We can do this with any path that we want to customize.
This is how we get:
1 That everyone can create their own organization of routes adapted to themselves.
2 Simple, traceable and accurate backups.
-- The text below is somewhat boring, and goes off topic. You can ignore it if you want --
Conclusion:
Linux allows you to be free, but it will require you to know it in depth.
To know it in depth it will not be easy for you.
Its directory and configuration structure is opaque.
It is "opaque" in an arbitrary and expendable way, it could be "readable."
Rethinking the directory system and configurations from 0 makes sense to me.
Someone sooner or later will end up creating a "readable" GNU/linux by default.
That does not mean that it ends up being the majority standard, nor does it need to be.
Freedom does not work for majorities, but for a sense of good.
And the possibilities of creating a sense of good are endless.
However, it must always respect a free model.
There are concepts implicit in freedom:
1 Self-defined identity: In order to be free you must first be.
2 System integrity: I am me and the relationship of my parts.
3 Independence.
4 Modular Relationship: In freedom there is no hierarchy (order) but organization. The module makes sense on its own when it is related and when it is not. The relationships (paths) must not break the integrity of the module, this is not free. The module must maintain its integrity to be able to freely create other relationships.
When UNIX dismembers an application into bin, share, etc., it makes it difficult for relationships to be established freely.
It could be write a book on "UNIX is not free." It's not opinion, it's logic.
The universe and nature follow a free model and give us many keys to how freedom works.
In nature there is no place where all the leaves of all the trees are.
Another one where all the trunks are, etc...
For freedom, UNIX is a failed organizational model with deep misconceptions.
For slavery and hierarchy it is the perfect model.
(I do not say anything and I say everything).
wow, but, if I'm allowed to say, you're delving into it by all the wrong reasons....
please don't go that way, you'll break your system in no time and all for nothing or no real benefit, sorry to tell.
hope you may recover from all this nightmare you're into. but then, when things start falling apart and not working at all or just barely, you'll remember this curse.
please
ps. besides, it's not unix nor linux that are there fooling you: it's mostly the LV2 plugin standard ontology and architecture that isn't that liberal if at all as for organizing things to your liking; you'll have to conform with it as much as you and me and everyone else can, like it or not; it's a staple of LV2 life, just live with it! ;)
re. Folder: LV2 presets don't work
so, the button should show a directory picker dialog but somehow it doesn't.
good catch!
UPDATE: fixed in qtractor >= 0.9.90.3git.2a0c1a, thanks.
Linux things
This time it is a functionality that I need to be able to have the plugins organized to my liking.
Now I have an incomprehensible problem when compiling.
"cmake -B build" tells me:
LV2 plug-in support. . . . . . . . . . . . . . .: No
All libraries are installed (the same ones from the last successful build I did).
I have reinstalled them to make sure.
CMakeLists.txt defaults to "lv2" support.
Linux things.
However, there is no problem, it is a functionality that I need, but it is not urgent.
I will continue using the default .lv2 folder for presets until the new version of Qtractor is released.
I don't like that it's a hidden folder.
I also prefer to be able to have these files under my own directory structure logic for the sake of simplifying possible backups.
But it's not something urgent.
Thank you.
Trick
I have configured it directly by editing "Qtractor.conf".
It's functional.
If someone else needs it, the variable is called:
Lv2PresetDir=
re. Linux things
I'm puzzled... what's this really about?
cheers
I'll try to be less scattered :S
I wanted to compile your arrangement to test, and above all to use, because I needed it (although not urgently).
I don't know why I didn't get compile. (Linux mysteries)
Then I realized that I could edit Qtractor.conf directly, and I shared the variable in case someone else wanted to configure it that way (without having to recompile Qtractor).
--- Info extra---
"what's this really about?"
There really is an underlying issue. I share it because it is something that I really think needs to be commented on, but of course I am not forcing anyone to read it.
It has nothing to do directly with Qtractor, but Qtractor is affected.
_We have a problem, and it is UNIX mode_
The hierarchical organization of Unix files is a great absurdity, and that causes problems.
I have already commented on these types of problems before in this forum (problems when sharing plugins, problems when creating your own file organization for a custom workflow...).
I knew those problems were there, but I didn't know the origin, I finally realized: UNIX mode.
Dismember the app identity into "bin", "etc", ".config", "share" is not functional.
And worse, it leaves "shared" resources out of reach of the user under administrative permissions. That "share" requires administrative permissions is a paradox in concept.
It makes it difficult and even prevents the user from locating and establishing their own organization.
Due to this nonsense, some programmers choose to save the resources of their programs in the user path in hidden!!! folders, others in the personal documents folder, others in the local .var, o .local or .config folders... Total chaos. (hidden!!!: Hiding doesn't help either.)
There are some initiatives that try to provide a solution:
- Appimages: Hiding the app's resources in a Zip doesn't seem like a solution to me.
- HelloSystem: A FreeBSD distro from the same author of Appimages that recreates Apple's System7 experience. I think it (like System7 and MacOX) have the same problem as Appimages.
https://hellosystem.github.io/docs/
- GoboLinux: I think it is a successful proposal, but it is still far from being friendly.
https://gobolinux.org/
(It is curious that perhaps Windows is the one that has the most accurate and free file organization.
Programs maintain an identity with their resources, their configurations, and are traceable.
User programs are differentiated from system applications.
Installable with a graphical interface that allows you to decide where to install, without conflicting with anything...)
_It's not a complaint, it's just a statement of a problem_
I can't create a Linux distribution that solves all this, I lack knowledge and resources.
I would be at the same point as GoboLinux, I would have to create installables (in my case with a Windows-style graphical interface) for the thousands of existing programs and maintain them. That is a task that requires many people.
What I can do is try to find solutions so that my user's file structure is the least dependent and most free. Also share my progress.
I can also report the problem, because until recently I was aware of its consequences, but not its origin.
Being aware of the root problem is the only way to find true solutions, and not patches.
We have a problem, and it is UNIX mode.
Greetings
re. Linux things...
aha I see...
and then you're beating on a dead horse... :) all that has been addressed by the freedesktop.org standards and recommendations already, and for quite some time...
take a note: Unix and Linux is not Windows, you certainly know that; windows is, in its loose file-system hierarchy model, if one may call it that way, and I bet young people might not remember, just because they're weren't born at the time, is just a PC/MS-DOS crappy disk/file model on steroids.
for quite some time, the Unix FHS is, yeah, The Standard, and it will probably prevail over the test of time: the windows/msdos crap will fade out to oblivion, give or take a century or two XD
cheers
We have different perspectives
I am glad that we can present them in this forum, because Qtractor is closely linked and conditioned to its ecosystem.
I could continue arguing why UNIX mode is a problem, but it makes no sense. For those whose UNIX mode does not generate conflicts, everything is fine.
For those who are not comfortable with UNIX mode (I'm not the only one, GoboLinux is proof of this), there is solutions, and it is precisely in the user folder.
I'm still working out my workflow. When I manage to solve it and test it for a few months I will share it.
Thank you
Custom paths | Linux thigns. Free but...
"Symbolic links" are the standard way to customize paths in Linux.
Being standard, they are reliable (It didn't take me months of testing as I thought.).
I have been an exclusively Linux user for more than 15 years.
However, I was unaware that the main functionality of symbolic links was to customize paths.
If there is another clueless person out there like me, the following example may be of help.
Example in the case at hand:
I want to customize ".lv2" not only for Qtractor, but for the entire system locally.
Steps:
We can do this with any path that we want to customize.
This is how we get:
1 That everyone can create their own organization of routes adapted to themselves.
2 Simple, traceable and accurate backups.
-- The text below is somewhat boring, and goes off topic. You can ignore it if you want --
Conclusion:
Linux allows you to be free, but it will require you to know it in depth.
To know it in depth it will not be easy for you.
Its directory and configuration structure is opaque.
It is "opaque" in an arbitrary and expendable way, it could be "readable."
Rethinking the directory system and configurations from 0 makes sense to me.
Someone sooner or later will end up creating a "readable" GNU/linux by default.
That does not mean that it ends up being the majority standard, nor does it need to be.
Freedom does not work for majorities, but for a sense of good.
And the possibilities of creating a sense of good are endless.
However, it must always respect a free model.
There are concepts implicit in freedom:
1 Self-defined identity: In order to be free you must first be.
2 System integrity: I am me and the relationship of my parts.
3 Independence.
4 Modular Relationship: In freedom there is no hierarchy (order) but organization. The module makes sense on its own when it is related and when it is not. The relationships (paths) must not break the integrity of the module, this is not free. The module must maintain its integrity to be able to freely create other relationships.
When UNIX dismembers an application into bin, share, etc., it makes it difficult for relationships to be established freely.
It could be write a book on "UNIX is not free." It's not opinion, it's logic.
The universe and nature follow a free model and give us many keys to how freedom works.
In nature there is no place where all the leaves of all the trees are.
Another one where all the trunks are, etc...
For freedom, UNIX is a failed organizational model with deep misconceptions.
For slavery and hierarchy it is the perfect model.
(I do not say anything and I say everything).
re. Custom paths | Linux thigns. Free but...
wow, but, if I'm allowed to say, you're delving into it by all the wrong reasons....
please don't go that way, you'll break your system in no time and all for nothing or no real benefit, sorry to tell.
hope you may recover from all this nightmare you're into. but then, when things start falling apart and not working at all or just barely, you'll remember this curse.
please
ps. besides, it's not unix nor linux that are there fooling you: it's mostly the LV2 plugin standard ontology and architecture that isn't that liberal if at all as for organizing things to your liking; you'll have to conform with it as much as you and me and everyone else can, like it or not; it's a staple of LV2 life, just live with it! ;)
Add new comment