Re: [LAD] samples/symlinks/sessions

On Mon, 2012-07-16 at 09:45 +0100, James Morris wrote:
> On 15/07/12 David Robillard <d@email-addr-hidden> 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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev