30 Mar
2012
30 Mar
'12
11 a.m.
On 03/30/2012 02:48 AM, J. Liles wrote:
given the "bizarre" behavior re. qtractor's session directory semantics,
this will work iif the SM creates its own session directory, on a per
client basis for instance, and then yes, clients are then asked to store
in there all their state data files and possibly the symlinks to all
their external data, under a managed session context.
the point here is that the client normal working directory (ie. its own
session directory) may not be the same as the SM's session directory.
nb. in the "bizarre" case of qtractor it's a must ;)
fair enough.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Thu, Mar 29, 2012 at 2:23 PM, Rui Nuno
Capela<rncbc(a)rncbc.org> wrote:
not quite. the qtractor session directory is a loose
session/project/song property than may be changed anytime by the user
and, most bizarre yet, it's not unique so it can be shared by more than
one qtractor session, project or song. it's more like a common place
than a central one, although, if the user so desires, it can remain the
same for many or all times.
what i am saying is that qtractor's session directory MAY NOT be the
same where its state data file gets eventually stored, be that from the
gui file menu or under SM control
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.