Dealing with existing projects is what the optional "Import to Session" and
Content-Type: text/plain; charset=UTF-8
On Thu, Apr 5, 2012 at 10:48 AM, David Robillard wrote:
> On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:
Anyway, FWIW the way I imported all my pre-existing project to NSM was very
1) Create a new session and add all the clients you used in your
2) Close that session and overwrite the the uniquely named project
files/directories that the NSM clients have created with the ones from your
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.
Content-Type: text/html; charset=UTF-8
On Thu, Apr 5, 2012 at 10:48 AM, David Robil=
On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:=
> On 04/05/2012 12:25 AM, David Robillard wrote:
... You specifically asked for input about Ardour's directories.<=
You keep calling the *goal* here a "restriction". =C2=A0Look, if =
you want to
just save an XML file with references to files who knows where, feel
free. =C2=A0Nobody is going to break in to your house and hold a gun to you=
head and make you do otherwise.
However, then any session containing qtractor will be fragile and
unarchivable. =C2=A0Why? =C2=A0Because the way you saved INHERENTLY makes t=
This isn't some arbitrary NSM "restriction" to make Rui Nuno =
life miserable, it's simply a necessary condition to make the desired
> iow. what if, assuming Ardour were about a fully-compliant NSM client<=
I agree that "open" should clearly work. =C2=A0The same amo=
unt of juggling
would have to happen regardless.
> otoh, if its native(gui file menu)-open is available, it would be dead=
> simple to get an existing qtractor project into a NSM session and
> file, though)
Assuming, conveniently, that all existing sessions are not archived
(.qtz) and all SM ones are. =C2=A0Otherwise, it's the exact same situat=
any other program. =C2=A0Notably, in this scheme, it's exactly the same=
any qtractor session saved within the SM. =C2=A0Same as Ardour but you tarr=
> perhaps, automatic symlinking of all the external files could be also<=
> levels 0 and 1+, in one fine blow, only if those file menu restriction=
> in, of course
One fine blow that just so happens to be qtractor *not* saving in the=
way you are so vehemently defending ;)
> aha. this seems the case for "edgy" applications like qtract=
It's not any different for any applications, loading existing stu=
loading existing stuff. =C2=A0Things will indeed need to be copied or moved=
Unfortunate, perhaps, but necessary.
Your knee-jerk desire to defend qtractor's saving scheme at all costs
with a death-by-emoticon blitzkrieg is obscuring the fact that all of
this is inherent to session management. =C2=A0Qtractor has problems with it=
because qtractor has problems with it. =C2=A0There is no working scheme
qtractor would have less problems with, because they are inherent
problems with qtractor + SM, not the SM itself.
Back in the realm of "solving problems" rather than "inflati=
there are two approaches you can use:
1) Completely save everything within the SM directory
2) Make your XML file point to links in the SM directory which point to
the configured store location
Sound familiar? =C2=A0It should, because it's precisely what every othe=
has to do to refer to "external files". =C2=A0Qtractor just uses =
as external files.
Of course, number 2 is completely pointless and silly unless sessions
share these files, but that doesn't really matter. =C2=A0The solution i=
same in any case.
You may not particularly like this because qtractor does not currently
save in either way, meaning you have to implement a new saving scheme,
but... well, qtractor simply doesn't currently save in a way that makes=
SM work. =C2=A0To make it do so, yep, obviously gonna be a bit of work,
because it doesn't right now.
If you don't want to support it, then simply don't support it, but =
try to paint that as a failing of the SM. =C2=A0It's not.
Dealing with existing projects is what the optional "=
Import to Session" and "Export from Session" commands are th=
ere for. These are basically Open and Save As but with *defined* semantics.=
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 use=
d 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 s=
ome other patchbay) and save so that JACKPatch will know the graph.4) R=
inse and repeat for other pre-existing projects.Since the system wa=
s 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 thi=
s can be automated with scripting. If a client implements an Import to Sess=
ion menu option, then basically it would just have to do the cp or mv itsel=
f (or if it lacks heavy state, then just open the file and be prepared to s=
ave it under the NSM path when the time comes.) But the SM has nothing to d=
o with it.