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 :).
re. Drumk1 & Samplv1 | More consistent relative paths...
this might be worth a try in this topic:
qtractor >= 1.5.11.2git.0688a0
cheers
ps. please check it out on the safe plane, that is saving any of your existing sessions to the side (Save As...) and validate if things just work as the same and not necessarily with samplv1 or drumkv1 lv2's involved, thanks.
:O Work
It works correctly with DrumkV1, so I assume it should work fine with any other LV2 plugin that implements the LV2 path system (not all LV2 plugins do this).
Now it's possible to create reliable backups according to the user's criteria without needing Qtz... THANK YOU!!!
Something I discovered while testing that blew my mind:
If I move the project... in "Recent Files" Qtractor updates the path... How can Qtractor know where I arbitrarily decided to move the project folder?
I'm still testing.
Test Conclusions
Drumkv1 and Samplv1 work perfectly.
I haven't been able to get it to work in another LV2 plugin, but for me, this is more than sufficient.
---
# Other observations:
The other plugins tested were Ninja2, LiquidSFZ, and SFIZZ.
I believe Ninja2 doesn't implement LV2 paths.
LiquidSFZ does, and although they are paths to SFZ files, they are paths nonetheless, so I believe they should work. Of course, the entire SFZ library was saved in the project root. It only works as an absolute path; as soon as the project folder is moved, it stops working.
SFIZZ has them implemented, but in a diferent way. In the code, it references the plugin's binary path (self).
PS: It seems SFIZZ's proposal for portability is that its samples be binary-relative. While this is a valid approach (my samples aren't lost, they travel with me), SFIZZ doesn't check if the path provided by the state matches its actual current path, nor does it modify and update it in the state. Without these checks, portability is lost. But only they can fix that.
---
# Conclusion:
It doesn't depend solely on whether it's LV2, but on how it's implemented in the plugin.
In this case, having Samplv1 and Drumkv1 function as expected is more than enough.
Furthermore, it makes sample behavior in Qtractor more consistent, since the plugin samples (in this case, only Samplv1 and Drumkv1) behave the same way as Qtractor's own samples in its tracks.
In other words, you ensure consistent sample usage between RNCBC creations.
thanks...
and happy new year (again?)
cheers ntl.
Add new comment