Re: [LAD] NSM - handling large files

On Thu, Mar 29, 2012 at 2:23 PM, Rui Nuno Capela <rncbc@email-addr-hidden> wrote:
>
> indeed. real life that is :)
>
> as far as qtractor is, all media content files, be that either audio or midi
> types, are ALL external files. it's true that some are created and edited
> under qtractor direct control, but they are all external. no exceptions.
>
> otoh, a qtractor session file (xml) is a listing or a map of references
> (links, paths, whatever) to those external files as they are in the
> file-system. but no, never symlinks.
>
> qtractor's "session directory" (aka. its own "session folder") is just an
> user preference, a location where all newly created media files (again,
> audio or midi, recorded or scratch) are located first time they get into
> existence--do not ever confuse this with any portable session directory or
> folder in any way. in fact, you get serious trouble if you do so. although
> there's this qtractor session archive/zip bundle file format (.qtz) which
> serves that particular purpose but as an option and convenience (just like
> an independent, moveable, self-contained zip-folder)

Are you saying that qtractor stores all audio and MIDI files that it
creates in one central folder? That seems quite bizarre. What is the
justification for doing that? How does it benefit the user?

> external or not, all-media content file "awareness" from a foreseeable
> session management entity, being that big or small, central or not, is, if
> you ask me, utopian.

It isn't utopian if one follows David's scheme. A file is a file is a
file (is a symlink). Instead of storing a path to the external file,
create an internal symlink to it and store the path to the symlink
instead. Simple and it allows *any* tool to find *all* of the external
data referred to by a session.

> sure, it would certainly be a really-good-thing(tm) to make a session
> archive portable across file-systems, machine architectures or platforms,
> users, networks, you name it... it really seems like an
> all-in-one/knows-it-all "goddess" application if you ask me. yuck! a
> pipe-dream if i reckon one :)

Well, I certainly agree that the actual need for this kind of
functionality is probably being overestimated.

> otoh. now in particular, those GUI (file menu) restrictions that NSM is
> posing on applications is something i won't comply to any time soon, not
> even later. so sorry. it's way too restrictive to me and my own belongings.
> from what i read, applications must then be modified to run in either of two
> or more awful different session modes eg. managed and non-managed? for
> x-sake, as if we hadn't enough of that already... i am so sorry again, but
> such a design won't fly much above the grass in my lawn... it gives me the
> shivers o,O
>
> but that maybe just a first glance pov. don't take it final

The point of those guidelines is to allow users to know *exactly* what
behavior they can expect.

The chief difficulty I had with implementing LASH support in programs
was that there was no answer as to what 'Save', 'Open', 'New', etc.
should do when running under LASH. Left, as is, the effect of these
operations would vary depending on how individual applications store
their state (whether fully in RAM, in a fixed location on disk, etc.).
This scenario is an absolute nightmare for both implementers and
users. If following a few simple rules to disable certain menu options
is enough to remove this ambiguity entirely, then why is that so hard
for you to accept? Do you *want* to make things ambiguous and
impossible to predict? I know I don't. The rules are not there to be
draconian and imposing--They are there to allow people to have
confidence in what running under session management means regarding
where their data is stored.

> however ;) imho, the SM should only know about application instances that
> are part of the so-called "session", their state of which only each
> application knows about their own, or so i believe, _and_ the means to
> recall that collected set of states later on. if that state is described by
> a set of files, so be it. let's name it state-data-files, or just call it
> _internal_ files perhaps?

I'm not sure what you mean, but to me it is obvious that only programs
which are connected to the session manager are subject to its control.

> more. a session manager (or its protocol spec) should not touch any, any at
> all, of the external (media content?) files that each application are
> possibly working on during their life span.

Of course it shouldn't.

> under the so called session's -folder (or -directory, if you prefer) there
> should be _only_ stored the state-data-files that pertain to each
> participant application. you guess it right, that's the state of each
> participating application instance at the time of the eventual
> "save-this-session-now!" command gets issued (a-la snapshot). and add to
> that the inter-connection state file(s) as it will be certainly the job of
> the SM to gather too. jack-session does this kind of stuff.

That's the idea... Except that in NSM, an application can store data
in its per-application area of the session *before* the first 'save'
command is ever delivered. This was a vital requirement of Non-DAW,
and, I believe, of any DAW like program.

> now back to square one. to make that whole session state, folder or
> directory, as an archival portable one is, quite frankly and imho again,
> utopian. nuff said :) but (oh no, not again), as a clever guy once said, the
> impossible turns out to be possible when there's someone foolish enough to
> do it ;)

I think that David has given a very convincing argument that it is not
only possible, but in fact a lot easier than people think.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Mar 30 04:15:02 2012