5 Apr
2012
5 Apr
'12
8:56 p.m.
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