Re: [LAD] samples/symlinks/sessions

On 16/07/12 David Robillard <d@email-addr-hidden> wrote:
>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

Any thoughts about symlinking to symlinked samples?

I decided to follow symlinks when storing sample paths in memory and
then recreate the symlink path when saving. This avoids symlinking to
symlinks. I believe it provided some other minor benefits but can't
exactly recall what they were now.

james.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Jul 20 20:15:02 2012