linuxaudio.org

On Thu, Mar 29, 2012 at 2:23 PM, Rui Nuno Capela  wrote:

quoted text
>

> 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

quoted text
> 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

quoted text
> 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

quoted text
> 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

quoted text
> 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

quoted text
> 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

quoted text
> 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

quoted text
> 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@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev