View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0008057 | ardour | bugs | public | 2020-04-25 14:47 | 2020-06-24 14:47 |
Reporter | agittins | Assigned To | johmue-eo | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | x86_64 | OS | Debian | OS Version | bullseye/sid |
Product Version | 6.0-pre1 | ||||
Summary | 0008057: Full path in template prevents sharing templates that include plugin presets. | ||||
Description | Ardour-6.0.rc1.44 (from nightlies) on Debian sid. Saving a session as a template results in the "template-dir" attribute in the session being set to the full path of my templates directory. This works fine on my machine, but if I share the template it won't open on other people's machines unless their OS and username match mine. I can't see anything in the code that indicates there might be a suitable workaround other than editing the template file directly when it's installed on another machine. I encountered this bug as I was trying to use Michael Willis' orchestral template from https://github.com/michaelwillis/virtual-playing-orchestra-ardour-template/ (recently updated to use sfizz instead of linuxsampler). It seems Michael first reported the issue in 2017 at https://discourse.ardour.org/t/templates-sometimes-include-absolute-paths-with-my-home-dir/89283 and commented again in January that he'd encountered the issue, but he seems unable to register with the tracker, so I thought I'd post it here for better visibility. There is also an issue raised for it at his template's issue queue at https://github.com/michaelwillis/virtual-playing-orchestra-ardour-template/issues/5 where some other users are also experiencing the issue. The same issue is also raised against the sfizz LV2 plugin (where I don't believe the bug lies) at https://github.com/sfztools/sfizz/issues/194 I expect this bug would affect any template that stores LV2 plugins, but I don't know enough about the API to be sure. It does appear though that it's Ardour that's responsible for choosing the filesystem location for state, so I think it's an Ardour bug, rather than a bug with the template, lv2 or the particular plugin(s). | ||||
Steps To Reproduce | Create a new empty session. Add an LV2 plugin to the master track (or a new track) and change some settings on it (eg, use sfizz and select an sfz file, or tweak some settings). Choose "File", "Save as Template". Note that the xml template file created in ~/.config/ardour6/templates/[templatename]/[templatename].template includes a full path for the plugin's state: ``` <Processor id="426" name="sfizz" active="1" user-latency="0" use-user-latency="0" type="lv2" unique-id="http://sfztools.github.io/sfizz" count="1" custom="0"> ...[snip]... <lv2 last-preset-uri="" last-preset-label="" parameter-changed-since-last-preset="0" template-dir="/home/agittins/.config/ardour6/templates/Untitled-2020-04-26-00-13-33" state-dir="state1"> ...[snip]... </Processor> ``` (note "template-dir" is a full path, not relative or tokenized) Attempt opening this template on another machine (or from a different user account) and the plugin state information is not restored to the session. Ardour6 logs to stdout: ``` ...[snip]... Set cursor set to default loading from /home/agittins/Music/mine/Untitled-2020-04-26-00-32-15 as Untitled-2020-04-26-00-32-15 templ /home/agittins/.config/ardour6/templates/Untitled-2020-04-26-00-13-33 is_new 1 bp 2 error: failed to open file /home/if-i-were-not-agittins/.config/ardour6/templates/Untitled-2020-04-26-00-13-33/426/state1/state.ttl (No such file or directory) lilv_state_restore(): error: lilv_state_restore() called on NULL state ...[snip]... ``` (note I changed the full path in the source template from "agittins" to "if-i-were-not-agittins" to simulate someone installing my template elsewhere). | ||||
Tags | template | ||||
|
Have you manually copied the files? If so you also have to manually adjust the path. The underlying issue is that liblilv unconditionally uses absolute paths to external files for all LV2 states. If you use Ardour's template-manager (Menu > Window > Templates) to export/import templates the path should be re-written during import. |
|
Can you confirm that it works when using the Template Manager? |
|
Ahh. I wasn't aware of the Template Manager (I failed to RTFM). I see (from the source) that the TM tokenises any instance of the template path with "$TEMPLATEDIR" which certainly addresses the issue if one uses that workflow. I've tested that and it works as expected. "The underlying issue is that liblilv unconditionally uses absolute paths to external files for all LV2 states." - Does liblilv directly read the ardour session xml? If not, then Ardour could conceivably build the absolute path when it passes it to liblilv, and it could store a relative (to project) path or a tokenised path (like the one exported templates) in the xml. But for the task at hand... As a matter of workflow, if one is building a template to share with other users, I guess one could: - export all templates (to, say, output.ardour-template-archive) - extract the archive (tar -xJf output.ardour-template-archive) - tar up just the template intended to share (tar -cvJf shinysharedtemplate.ardour-template-archive templates/shiny-shared-template - distribute shinysharedtemplate.ardour-template-archive to anyone that wants it Alternatively, one could: - copy the template - edit the templatename/templatename.template file and replace any instance of their local template path with "$TEMPLATEDIR" - tar it up and distribute as before So.... should this become a feature request for the template manager to have an "Export Selected" button? |
|
I think there was some reason, why I haven't implemented "Export selected" but I honestly don't remember now. Anyway, I plan to do some improvements to the Template Manager after 6.0, then I will look into this. |
|
BTW, while you are already testing the template manager. Do you have real world templates with plugin settings that you export from Ardour5 and import into Ardour6. Please report any issues that come up when doing that. That's an important usecase for the template manager for A6, as many people probably will need to do that. |
|
Great, will do. The Virtual Performing Orchestra template mentioned above was created by 5.12 and I've been importing it into 6.0-rc1.44 and it seems to behave sensibly. The template has issues that I think are unrelated to Ardour as such, so a bit hard to say for sure. I had another template that came over (automatically?) from Ardour 5.12 without any problems, and a track template as well. Happy for you to close this bug now, shall I raise a new feature request for the "Export Selected"? It would make sharing templates a no-brainer so it's a worthwhile feature, I think. |
|
I have created a new feature request for "Export Selected" at https://mantis.ardour.org/view.php?id=8074 This bug can be closed as "RTFM" / "invalid assumptions" or similar :-) |
|
Issue has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-04-25 14:47 | agittins | New Issue | |
2020-04-25 14:47 | agittins | Tag Attached: template | |
2020-04-25 16:05 | x42 | Note Added: 0023912 | |
2020-04-25 16:13 | johmue-eo | Assigned To | => johmue-eo |
2020-04-25 16:13 | johmue-eo | Status | new => feedback |
2020-04-25 16:19 | x42 | Note Added: 0023914 | |
2020-04-25 19:40 | agittins | Note Added: 0023916 | |
2020-04-25 19:40 | agittins | Status | feedback => assigned |
2020-04-25 19:57 | johmue-eo | Note Added: 0023918 | |
2020-04-25 20:00 | johmue-eo | Note Added: 0023919 | |
2020-04-25 20:00 | johmue-eo | Note Edited: 0023919 | |
2020-04-25 22:50 | agittins | Note Added: 0023921 | |
2020-05-02 07:46 | agittins | Note Added: 0024032 | |
2020-05-03 12:09 | x42 | Status | assigned => resolved |
2020-05-03 12:09 | x42 | Resolution | open => no change required |
2020-06-24 14:47 | anonymous | Note Added: 0024499 | |
2020-06-24 14:47 | anonymous | Status | resolved => closed |