On 03/29/2012 02:44 PM, Emanuel Rumpf wrote:
Back to life - back to reality
1. We start qtractor as part of a session, create some midi-tracks,
include some external wav-files.
Should the SM "know" about these external files, as I suggested ?
(Allowing the user to find out basic info about it. )
Or leave it completely to qtractor ?
2. We record a new file in qtractor. Where would it be stored ?
Should the SM "know" about this file ?
3. A session is duplicated.
How does the SM handle the recorded and external files =
4. A session is exported.
Jonathan said, current practice is a simple directory copy.
Well ! Simple and not bad at all.
But what about the external files ?
Just make some symlinks for them ?
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)
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.
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 :)
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
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?
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.
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.
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 ;)
my 2c
--
rncbc aka Rui Nuno Capela
[email protected]
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
