On Sun, 2012-03-04 at 12:37 -0800, J. Liles wrote: > On Sun, Mar 4, 2012 at 9:38 AM, David Robillard <[email protected]> wrote: [...] > > However, the new LV2 state stuff is specifically designed to allow > > self-contained archival/export with any session manager[1]. Hopefully a > > future version of IR will move to it. I don't know anything about NSM's > > facilities for export/archival, though. > > > > -dr > > > > [1] My preferred implementation is using symlinks to refer to external > > files, so any tool, even tar -h, can archive correctly. KISS. > > > > We must remember not to take this to a level of absurdity. For > instance, I don't believe that it is necessary to, for example, > copy/symlink LADSPA or LV2 plugin binaries themselves into a session.
I agree. Some fancy automatic mechanism to resolve missing plugins somehow might be nice, but that's orthogonal. Plugin binaries definitely do not belong in saved sessions. (Plugins using files *whatsoever* should be discouraged, but sometimes it's truly necessary) > This doesn't just apply to > plugins, but to soundfonts, generic sample libraries, etc. What should > be stored in the session is only what is specific to the session, and > that sometimes includes a selection between generic external entities. This is only true *sometimes*. If you are saving a session locally, sure, you don't want to copy everything it touches into the save directory (possibly many times). However, the ability to completely archive a session, including samples and such, is a very important ability. Sessions aren't very useful if I can't make one, send it to you, and have us collaborate. Or make one, archive it, and load it up later on some other machine and actually have it work. If you get hundreds of unresolved file references to mysterious paths on some other machine, the system has utterly failed to do its job. Put in other terms, the session shouldn't *always* be archived, but the ability to archive sessions is crucial. > If you use symlinks to cover the gray-area case of a non-generic > llibrary of impulse waveforms, that's fine and it would work for > archiving, but the point remains that if you don't create the symlink > and I attempt to load a copy of the session in a different > environment, I would expect to be told by the software what exactly is > missing. In terms of the plugin interface, all that happens is the host gets the opportunity to map any paths the plugin saves to its state. This way, it can implement any behaviour. Symlinks just happen to be the best and simplest one, all things considered. Instead of inventing some new file format everyone has to deal with and erecting some bloated framework to accomplish all this, you just archive the thing and resolve symlinks. Good old fashioned tar can even do it (both full and shallow archival). It's also very convenient that what's going on is very clear at the file system level, you can see precisely what files are referred to just by looking at a directory listing, and you can even resolve broken links manually with generic tools (i.e. ln). All of this becomes a real nightmare if the paths are buried in some XML file, or whatever. I guess it's summed up nicely by the fact that you can do all of the following without any dependency on a particular API or file format whatsoever: * Report and/or resolve missing files in the session * Do a shallow archival of the session * Do a deep archival of the session which will load on other systems without any missing data * Do all of the above recursively (sessions within sessions) with zero additional effort Of course, this isn't mandated by LV2 or anything, but the friction you'd have to overcome to achieve the same with a bloated pile of unnecessary garbage is so massive it's the only realistic solution for "plugins with files in hosts in session managers". It relieves the burden of session managers having to have an interface specifically for this and hosts having to implement it (which, even if you did, means you'd have to launch the host just to export an existing session). > Obviously, solving the problem is as simple as going back to > the creator of the session and saying "Hey, I need this external > object in order to fully load your session." This might be simple, but it might also be completely impossible. I agree it should be possible to implement this behaviour (to share lightweight sessions among people who do share a common set of data), but it also must be possible to do a true self-contained export. Luckily though, all of this boils down to a very simple requirement: the host must be given the opportunity to do <whatever> to paths. > BTW, I don't know if LV2 supports this, but if it allows plugins to > *SAVE* non-generic (that is to say, session specific) data wherever > they want on the filesystem, then that, IMHO, is badly broken. There > may be nothing technical that can be done about it, but you should at > the very least be able to point at a section of the API document and > say to the developer of such a plugin: Fix it, it's broken. I fully agree. Plugins that create files in some random location are the ultimate evil. The above basically boils down to "you can use files, but the host must know about it". It is indeed explicitly mentioned in the state spec. (A sometimes overlooked sidenote: this applies to ALL files, not just at save time. I have heard that the commercial stuff fails in this regard, so advanced plugins (e.g. that record) tend to create files in random locations, thus breaking sessions. The LV2 spec explicitly requires ALL paths to be created via the host callback, including those used at runtime for recording and such. This is also necessary to ensure possibly large files are created on the correct volume.) -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
