[LAD] NSM - handling large files

[David Robillard]

On Thu, 2012-04-05 at 11:14 -0700, J. Liles wrote:
[...]
> 
> Dealing with existing projects is what the optional "Import to
> Session" and "Export from Session" commands are there for. These are
> basically Open and Save As but with *defined* semantics. 

My mistake, I was just going by what Rui wrote and didn't refer back.

> Anyway, FWIW the way I imported all my pre-existing project to NSM was
> very simple:
> 
> 1) Create a new session and add all the clients you used in your
> non-managed setup.
> 2) Close that session and overwrite the the uniquely named project
> files/directories that the NSM clients have created with the ones from
> your non-managed-setup
> 3) Open the project and restore JACK connections (either manually or
> with some other patchbay) and save so that JACKPatch will know the
> graph.
> 4) Rinse and repeat for other pre-existing projects.
> 
> Since the system was designed to work with the Unix files/directories
> model (instead of e.g. a database), I don't consider the user mv'ing,
> symlinking etc to be hacks, but just normal usage.
> 
> Depending on how organized your pre-existing projects were, much of
> this can be automated with scripting. If a client implements an Import
> to Session menu option, then basically it would just have to do the cp
> or mv itself (or if it lacks heavy state, then just open the file and
> be prepared to save it under the NSM path when the time comes.) But
> the SM has nothing to do with it.

Makes sense.

>From a user friendly POV it would of course be nice if apps implement
that, though, as you say, the SM has nothing to do with it.  That the
actual stuff that needs to happen is something the user *could* easily
do if they wanted to is a good thing.

-dr