On Mon, 2012-07-16 at 09:45 +0100, James Morris wrote:
On 15/07/12 David Robillard <d(a)drobilla.net>
wrote:
On Fri, 2012-07-13 at 15:57 +0100, James Morris
wrote:
Hi,
My sampler app has Non Session Mangement implemented but is currently
still referring to external files by their original path.
I want to use the symlink method as discussed fairly extensively here
but I'd like to know if there is any recommended strategy for naming
the symlink of a sample.
It could so happen that as far as the filesystem is concerned the
only discerning uniqueness between two samples is in the path (ie
kit1/snare1.wav and kit2/snare1.wav).
I've come up with three possible solutions to this (in my current
order of preference):
1) symlink-to-sample created in a subdir named using a hash* of the
full path to external file
2) painstakingly re-create the full path within the session dir and
add the symlink into that.
3) some horrible text manipulation of the full path (ie replace /
with _) that is bound to fail.
* J. Liles mentioned SHA1 here:
http://linuxaudio.org/mailarchive/lad/2012/3/30/189343
Are there other/better options or disagreements about (1) being a
good choice over the other options I've presented?
I just used the original name of the file, with a number added for
uniqueness if necessary (which is very seldom the case). It works and
is much more human-friendly and straightforward than the above options.
A "make this path unique by sticking a number on the end of it"
function turns out to be pretty useful anyway.
Of course, you need to actually check for existence of files to create
it, which might be a problem in some cases (though not any I've
encountered), but anything that assumes a mapping based on the current
path is a unique identifier for a particular file's contents is bound
to fail anyway.
Well I spent what time I had free over the weekend implementing the
first option. I did take a look beforehand to see what NON-Daw did
(it does what you recommend), but disliked how it didn't check for an
existing symlink pointing to the file it was creating a new symlink for.
I decided checking existence of one directory to be easier than
examing each symlink in a directory to see where it points. However I'd
not be surprised if these benefits were outweighed by other costs.
FWIW, since I originally did quite a bit of advocating of this scheme
because of my experience doing it for plugins, I should mention an
important part of the system there:
The *host* gets to make all these decisions.
e.g. the host could make symlinks, or always copy, or use hashing and
copy when necessary, or just let things use absolute path references,
and so on. This is achieved with a callback to map paths to/from state.
It might be nice for a session manager to be able to do the same thing,
though this means a round-trip for each path, and is likely much less
feasible for a host of other reasons (a one-file C "library" to Do The
Right Thing is probably more useful), but I thought I'd mention it.
Cheers,
-dr