By deduction. I skimmed the Drumkv1 code (its lv2 part) and saw that it managed the path types, but didn't declare them, so I deduced it must be Qtractor, which is why I posted it here and not in the Drumkv1 forum.
Thanks for replying. I'm left with the conclusion that it's simply not viable.
Everything that follows can be ignored.
...
After your reply, I studied LV2 a bit more and understood:
FreePaths are not relative paths, but simply the release of memory for the path.
AbstractPaths are not exactly relative paths, but they serve an equivalent function. They are a unique path ID that the host then replaces with the absolute path according to its criteria. The host determines this.
The entity responsible for saving the files is not the host, but the lv2 API through makePath. So, my second idea is unfeasible, as you point out.
I think I understand that:
At some point, the host (Qtractor) must tell the API that it's a .qtz file and therefore wants those samples to be saved and marked as AbstractPath.
So, what I'm proposing could be possible; that is, if the condition is met that the samples are located in the project folder within the .qtr files, saving to .qtr marks those paths as AbstractPath.
However, this isn't possible in Qtractor because the plugin information isn't viewable, only executable, as it's encoded in base4 blob. Therefore, it's impossible to know if the condition is met. My question is: can it be decoded?
I did a test with Samplv1 on another host (Carla) that doesn't encode state information in its .carxp file. The surprise was significant. It only saves the sample name, not the path. I thought to myself: so Carla saves the absolute path in its configurations, and if I delete Carla's configurations, it shouldn't be able to locate the file. Well, it does locate it...
Conclusion... I don't understand anything.
It seems paradoxical to me that mapPath was created to guarantee portability, but in practice, it's inapplicable:
"
"This is necessary so that hosts can handle file system references correctly, for example to share common files, or bundle state for distribution or archiving."
Qtractor's solution with .qtz is incomplete, since it doesn't allow attaching arbitrary files, such as documentation, plugins, sample libraries, etc.
These could be saved alongside the .qtz file in the same folder; however, there are other non-LV2 plugins whose way of guaranteeing portability is precisely by saving the sample libraries in the project root, and this isn't feasible with .qtz.
There's a trick: save it as .qtz, then as qtr (which marks the level 2 plugin samples as abstract), and then prepare the project so the rest of the plugins are portable.
It's laborious, and it should be possible to automate it with scripts, but since the data is hardcoded... it has to be done manually :).
By deduction. I skimmed the Drumkv1 code (its lv2 part) and saw that it managed the path types, but didn't declare them, so I deduced it must be Qtractor, which is why I posted it here and not in the Drumkv1 forum.
Thanks for replying. I'm left with the conclusion that it's simply not viable.
Everything that follows can be ignored.
...
After your reply, I studied LV2 a bit more and understood:
FreePaths are not relative paths, but simply the release of memory for the path.
AbstractPaths are not exactly relative paths, but they serve an equivalent function. They are a unique path ID that the host then replaces with the absolute path according to its criteria. The host determines this.
The entity responsible for saving the files is not the host, but the lv2 API through makePath. So, my second idea is unfeasible, as you point out.
I think I understand that:
At some point, the host (Qtractor) must tell the API that it's a .qtz file and therefore wants those samples to be saved and marked as AbstractPath.
So, what I'm proposing could be possible; that is, if the condition is met that the samples are located in the project folder within the .qtr files, saving to .qtr marks those paths as AbstractPath.
However, this isn't possible in Qtractor because the plugin information isn't viewable, only executable, as it's encoded in base4 blob. Therefore, it's impossible to know if the condition is met. My question is: can it be decoded?
I did a test with Samplv1 on another host (Carla) that doesn't encode state information in its .carxp file. The surprise was significant. It only saves the sample name, not the path. I thought to myself: so Carla saves the absolute path in its configurations, and if I delete Carla's configurations, it shouldn't be able to locate the file. Well, it does locate it...
Conclusion... I don't understand anything.
It seems paradoxical to me that mapPath was created to guarantee portability, but in practice, it's inapplicable:
https://lv2plug.in/ns/ext/state#mapPath
"
"This is necessary so that hosts can handle file system references correctly, for example to share common files, or bundle state for distribution or archiving."
Qtractor's solution with .qtz is incomplete, since it doesn't allow attaching arbitrary files, such as documentation, plugins, sample libraries, etc.
These could be saved alongside the .qtz file in the same folder; however, there are other non-LV2 plugins whose way of guaranteeing portability is precisely by saving the sample libraries in the project root, and this isn't feasible with .qtz.
There's a trick: save it as .qtz, then as qtr (which marks the level 2 plugin samples as abstract), and then prepare the project so the rest of the plugins are portable.
It's laborious, and it should be possible to automate it with scripts, but since the data is hardcoded... it has to be done manually :).