First things first. Happy New Year to everyone!!!
Hi Rui:
If I understand correctly, when we save in Qtz, the Drumkv1 and Samplv1 samples are marked as relative (FREE_PATH) by Qtractor.
I think that in addition to this behavior, it would make sense for them to also be marked as relative in Qtr sessions if the samples are located within the project folder (it doesn't matter if it's in the root of the project folder or in subfolders within the project folder).
Something like:
AbsolutePathProjectFolder = /path/project/X
AbsolutePathSample = /path/project/x/samples/kit/kit1.ogg
If (AbsolutePathSample.find(AbsolutePathProjectFolder)) {
Mark the path as FREE_PATH;
}
Another idea for Drumkv1.
If I use a single sample to create multiple instruments, saving in Qtz saves a copy of the same sample for each instrument.
I think the best approach would be to create an array with all the samples to be saved, excluding duplicates, before saving, and assign each path a unique, incremental ID.
The samples could be saved as:
1_snare.ogg, where 1 is the path identifier.
If I use another snare.ogg file belonging to a different kit with a different path (let's say that path is marked with ID 126), it would be saved as:
126_snare.ogg
Since each path is unique, there's no risk of overwriting one file with another with the same name.
This way, we would only have the samples we actually need saved, without duplicates.
As always, just ideas... :)
Thanks for everything.
re. Drumk1 & Samplv1 | More consistent relative paths...
where are you looking to those paths anyhow?
in both .qtr and .qtz the LV2 plugin state are stored as an opaque blob base4 encoded.
what you're probably arguing is that, on the .qtr case, the paths there are not stored relative to the session file location and that's true (and a curse for session portability if I understand you correctly ;))
however, this and your other idea for drumkv1 are not that fixable, if at all, just because it's all under LV2 plugin state and API realm... so it's all not quite about samplv1 and drumkv1 in particular, but LV2 plugins in general, sorry.
hyu.
cheers
re. where are you looking to those paths anyhow?
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 :).
Add new comment