Re: [LAD] NSM - handling large files

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Apr 5 20:15:02 2012