On Mon, Apr 2, 2012 at 11:29 AM, Emanuel Rumpf <[email protected]> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
