On Thu, Apr 5, 2012 at 10:48 AM, David Robillard <[email protected]
<mailto:[email protected]>> wrote:
On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:
> On 04/05/2012 12:25 AM, David Robillard wrote:
> > On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
> > [...]
> >> ardour gets all its stuff under one own session directory, on
a per
> >> session/project basis, iirc just like NSM mandates,
> >>
> >> bbbuuuuuut...:) making that one and the same directory as from an
> >> outsider/independent session manager like NSM is asking for a
lot of
> >> file and symlink juggling, if you ask me
[...]
> > A directory of files is a directory of files. The format
Ardour would
> > save to inside of a session is precisely the same format it already
> > saves in, perhaps with some things being links.
[...]
> ok then.
>
> but again, i was implying about the NSM session directory location
> restriction, not ardour's session/project directory/file format.
... You specifically asked for input about Ardour's directories.
You keep calling the *goal* here a "restriction". Look, if you want to
just save an XML file with references to files who knows where, feel
free. Nobody is going to break in to your house and hold a gun to your
head and make you do otherwise.
However, then any session containing qtractor will be fragile and
unarchivable. Why? Because the way you saved INHERENTLY makes that so.
This isn't some arbitrary NSM "restriction" to make Rui Nuno Capela's
life miserable, it's simply a necessary condition to make the desired
behaviour possible.
> iow. what if, assuming Ardour were about a fully-compliant NSM client
> and you want to open an existing Ardour session, one you've been
working
> hard previously but stand-lone ie. outside the NSM umbrella? i
read that
> you'll have to copy or move all ardour's session files _manually_
first,
> or symlink at best, into the NSM's central/root directory and
guess what
> and where. that's the kind of "cheat" or "juggling" i was telling you
> about :)
I agree that "open" should clearly work. The same amount 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
> behold: later, the NSM would just save (a new stanza) of the qtractor
> session/state file under the SM's designated central directory
location
> and that's perfect for qtractor, see? because all qtractor media
content
> files are external and independent of the state file. and if you (the
> user) selects the archive/zip bundle format (.qtz suffix) as default,
> then we'll get *all* qtractor project stuff under the nominated NSM
> session directory tree (already compressed into one single
archive/zip
> file, though)
Assuming, conveniently, that all existing sessions are not archived
(.qtz) and all SM ones are. Otherwise, it's the exact same situation as
any other program. Notably, in this scheme, it's exactly the same for
any qtractor session saved within the SM. Same as Ardour but you tarred
it.
> perhaps, automatic symlinking of all the external files could be also
> doable at the NSM-Save instant, 'coz qtractor state is, among other
> important things, an inventory map of all those files anyway--some
> invasive coding required, though ;)
>
> looks like, after all, that qtractor could stand compliant to
both NSM
> levels 0 and 1+, in one fine blow, only if those file menu
restrictions
> get subverted or just plainly ignored:o) and all the code to
comply with
> the basic NSM API announce, open, save, close... gets eventually
coded
> 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 qtractor, when
> their own file new, open, save, and save as... menu operations
are made
> completely orthogonal and independent of any general SM open/save
ones.
>
> try that with the not-so-edgy (mainstream?) applications ;)
It's not any different for any applications, loading existing stuff is
loading existing stuff. Things 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. Qtractor has problems with it
because qtractor has problems with it. There 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 "inflating egos",
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? It should, because it's precisely what every other app
has to do to refer to "external files". Qtractor just uses every file
as external files.
Of course, number 2 is completely pointless and silly unless sessions
share these files, but that doesn't really matter. The solution is the
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. To 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 don't
try to paint that as a failing of the SM. It's not.
-dr
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.
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.
