I can’t answer for the big studios, but I do mainly make a living as a sound engineer. Your disaster will most likely never happen to me and hopefully not to other studios either. In my case, it’s a few reasons:
I never, ever upgrade a system or a DAW when working on a project. Such an upgrade will only happen between projects.
I only mix audio files. Everything is consolidated and all MIDI is bounced to audio files
I have every raw file (unprocessed or tracked file) any customer ever sent me up to this day
I still have working machines (4 of them) with DAW’s and plugins that can handle projects that are up to 20 years old
Backups, backups, and backups
When mixing, I also make stems from the multi-tracks and keep them, something I’ve done for years. It still happens that a customer asks me to make new backing tracks on very old material, no problem.
Of course, even when I do anything I can to avoid disasters I believe I’m aware that anything can happen, and hopefully, I can recover fast if needed.
I want to bring a new perspective to the discussion. The modern electronic music producers needs a decent sampler built into the daw, like Abletons Simper/sampler. The main workflow benefit these samplers (at least in ableton) can offer, that no external plugin can (At least I think so) is: I can click " Collect All and Save" in Ableton and all samples (no matter where I imported them from) are saved in the project folder and the samples in the sampler instances get updated. This is a huge benefit as the project becomes independend from one users filesystem and allows collaboration. This is not possible with ardour at the moment, right?
Yes, I know that this feature exists, but it doesn’t apply to files INSIDE of plugins, such as lsp sampler or sfizz for example…
Would it be possible to implement such a feature in a plugin?
It works for plugins that support it saving the state with the session. That includes most VST3 and many LV2 plugins. e.g ACE fluidsynth, that comes with Ardour.
The host has no information whether a plugin relies on external files, so the best the host (here Ardour) can do is to ask the plugin to save externally used files with the session.
Please file a bug with LSP sampler and sfizz if they do no honor this request.
I can offer an example with available source-code eg. x42 Zero Config|Latency Convolver custom loaded impulse response files are saved with the session it ends up in the externals/ folder.
For VST2/3 plugins the file is usually encoded and saved directly in the .ardour session file.
Interesting, I did not know this was possible. So if I understand correclty: It would be possible for external plugins to know when the “Bring all media into the session folder” in ardour is pressed and act acordingly?
Ardour always asks plugins to save their externally used files with the session, every time the session is stored.
“Bring all media into the session folder” is only for the case when a user has changed the default that importing files to Ardour always copies those files to the session.
Because the external is being saved as a relative symlink, it can get broken, e.g. when copying / renaming the Ardour session. I don’t know whether saving as a relative link is the fault / choice of sfizz or Ardour.
Hmm, I think I wasn’t clear: I meant that the symlink is being created using a relative path (the ../../../../../../../sounds/sfz path prefix), versus the absolute path used when selecting the file (/media/<userid>/sounds/sfz). The relative path seems to break frequently, e.g. when using Save As, etc.
In any case, having the .sfz file hard-linked into the Ardour session’s externals/ subdir would be disastrous: the SFZ spec assumes that sample files can be found by dead-reckoning from the directory containing the .sfz file. Creating a hard link strips away any knowledge of the “source” path.
…and a quick glance at for instance LV2 state, I think this is on the plugin to manage better in that case is my understanding.
This is likely why symlinks are created rather than hard links by sfizz (Which is correct is debateable and will change depending on the exact needs in question IMO) but the use of relative path symlinks then is a bit weird. Not sure if that is because it doesn’t know it’s absolute path or not, haven’t dug that far into it.
Of course the alternative would be to hardlink in everything needed for the plugin, as I alluded to above, but there is a potential of a lot of disk space being used to do so if the session was copied, moved, etc. As I mentioned, I think whether this is the right method to choose will depend on the person and needs in question more than anything. For instance multiple small SFZ libraries I might want copied with the session, but if talking about multiple multi-gig libraries, maybe not so much:)
Ardour provides a location “please store any additional data here” (externals/).
Then the plugin asks liblilv to save each file in an architecture independent way in that folder, via LV2_State_Map_Path::abstract_path, which uses sym- or hardlink (see lilv/src/state.c).
The plugin does not have to use LV2_State_Map_Path and could do something else though.
A hardlink is ideal though. That does not require extra space, the file is retained if other copies are moved or removed. However it only works for files (sfz are often folders with many files). Also the files need to be on the same filesystem.
It is not fully functional on macOS though. I think they need to purchase a signature to create a permission elevation helper.
But that is an Apple stupidity quirk .
digression on macOS security rant
(the certificate monopoly, not the security model. I think it is quite smart to limit certain elevations to sub process calls and allow those only by programs with matching signature. But I would prefer to have a choice of certificate authority. Apple is after all not doing manual review, but applying heuristics etc. to automate the screening process for maximum financial gain. This leads to the occasional slip through of bad acting code. The worst thing though is the futility of asking user consent for so many things. The more noise, the less vigilant users become. People will agree to whatever prompt to just get over with it)
back to Owlplug itself, I like the ideas a lot. Simple git repositories as download sources. Expandable. Decentralized. If they finish this and build their shop around it, I whish them all the success possible. Selling plugins is a tough business these days.
In the Linux world, the solution to this would be a NixOS based distribution. You can have multiple versions of the same software at the same time with a unique snapshot of their configuration, depedencies and build arguments, and with “generations” you can switch between different versions of the system.
That is, this session was created with Ardour 7.1 and such and such plugin/versions, you launch the session in that environment. Another session was created with Ardour 8.1 and different plugins/versions, you launch that session in that environment.
You can continue upgrading your system and applications well into the future, and still be able to launch that exact set of packages from 10 years ago.
The obvious obstacle is that it would be quite an undertaking to create such an Audio distro for non-tech people. Nothing undoable and maybe not as hard as it initially sounds, but it would certainly require a small community around it. At the very least it will need some work to make audio plugins play with the Nix package manager.
A gentle reminder that many of the most significant, important and widely used plugins come from developers who do not use libre or open source licenses, and do not permit redistribution of their work.
While I obviously consider it an admirable goal to create a libre, open source “equivalent” of tools that facilitate as much creativity and creation as possible, we are still relatively far from that at this time.
I would also note that just the standard environment variables $PATH and $LD_LIBRARY_PATH can be used to give you a substantial part of what NixOS promises.
I have a suggestion. What about possibly of adding a section in the reference manual, an appendix, that would have various links to open source / free plugins ? Maybe limit it to plug-ins of high quality and cross platform ?
It would give new users a resource to go to. Dexed and Surge XT are excellent. There are plenty of good lv2 and ldspa plug ins that are aged, but still work well enough.
In Ardour, under help, there can be a option that will open the reference manual page about the plug ins.
I understand, my suggestion was not to distribute plugins through the Nix repositories. It could be that the user downloads them through the vendor directly after the purchase, but then registers them through a tool that integrates with Nix package management/configuration so that it is placed in a folder that Nix knows where the exact version of the plugin is located.
