Re: [LAD] NSM - handling large files

On Mon, Apr 2, 2012 at 11:29 AM, Emanuel Rumpf <xbran@email-addr-hidden> wrote:
> I thought - that's what we would not want: store large files in the
> session dir !?
> ....because duplicating a session should stay a "light" and fast process.

Personally, I'm fine with having large files in my session
directories. In fact, that's exactly where I want them. Why would one
one to duplicate a session with a lot of pre-recorded audio? And,
anyway, this could be made to work by just storing that common audio
wherever you want and making 'external' references to it in the
session (and hopefully the application involved uses the symlink
technique we've discussed for referring to external files)--all
without the SM having to know anything about it.

> That is, why I had been proposing an "nsm-large-files" directory
> (outside of the session-folder), for those,
> but actually, it doesn't matter, _where_ NSM-clients store their "large-files",
> as long as they create symlinks for them in the session folder.

Right. As long as there are symlinks it's fine, except that I think it
should be the user deciding where things are stored rather than
individual applications.

Remember, you can always write a simple shell script that moves WAVE
files etc. into a central location outside of the session directories
and replaces them with symlinks. Again, this would be the user
deciding what to do and the SM or the application doesn't have to know
anything about it.

I think this is very much a corner case anyway. Normally, one wants
all the project data and media to be stored on the same filesystem, as
close together as possible, and doesn't care about being able to
duplicate a session with gigabytes of audio data (because... why are
you doing that anyway and why are you doing it so frequently that just
creating the symlinks yourself is too much trouble). Unless the use
case is very compelling, it's hard to justify adding any complexity or
requirements to either the SM or the client applications. Remember,
this is Unix--we don't have to stuff all the functionality into one
tool.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Apr 3 00:15:02 2012