[LAD] NSM - handling large files

J. Liles malnourite at gmail.com
Thu Apr 5 18:14:56 UTC 2012


On Thu, Apr 5, 2012 at 10:48 AM, David Robillard <d at drobilla.net> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20120405/0bd9dc42/attachment.html>


More information about the Linux-audio-dev mailing list