[LAD] NSM - handling large files

Rui Nuno Capela rncbc at rncbc.org
Thu Mar 29 21:23:30 UTC 2012


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
rncbc at rncbc.org



More information about the Linux-audio-dev mailing list