On Thu, Mar 29, 2012 at 2:23 PM, Rui Nuno Capela wrote:
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
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
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
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
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
Of course it shouldn't.
> under the so called session's -folder (or -directory, if you prefer) there
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
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