[LAD] NSM - handling large files

[Rui Nuno Capela]

On 04/05/2012 12:25 AM, David Robillard wrote:
> On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
> [...]
>> ardour gets all its stuff under one own session directory, on a per
>> session/project basis, iirc just like NSM mandates,
>>
>> bbbuuuuuut...:) making that one and the same directory as from an
>> outsider/independent session manager like NSM is asking for a lot of
>> file and symlink juggling, if you ask me
>>
>> i'm not an expert in ardour internals, someone else could chime in and
>> help me here.
>
> I don't know what you are trying to say.  "One and the same directory as
> from an outsider/independent session manager"?  Huh?
>
> A directory of files is a directory of files.  The format Ardour would
> save to inside of a session is precisely the same format it already
> saves in, perhaps with some things being links.
>
> I can guarantee you that much, because if it had to be different,
> Ardour, like presumably most apps, simply would never implement it...
>

ok then.

but again, i was implying about the NSM session directory location 
restriction, not ardour's session/project directory/file format.

let me thrown in some more ;)

from what I read on the NSM User & API specs. you can only create new, 
open and save NSM-managed sessions as in each participating client 
project's sub-directories. existing individual projects are out of the 
picture. unless you "cheat" the NSM o.O

iow. what if, assuming Ardour were about a fully-compliant NSM client 
and you want to open an existing Ardour session, one you've been working 
hard previously but stand-lone ie. outside the NSM umbrella? i read that 
you'll have to copy or move all ardour's session files _manually_ first, 
or symlink at best, into the NSM's central/root directory and guess what 
and where. that's the kind of "cheat" or "juggling" i was telling you 
about :)

otoh, if its native(gui file menu)-open is available, it would be dead 
simple to get an existing qtractor project into a NSM session and 
behold: later, the NSM would just save (a new stanza) of the qtractor 
session/state file under the SM's designated central directory location 
and that's perfect for qtractor, see? because all qtractor media content 
files are external and independent of the state file. and if you (the 
user) selects the archive/zip bundle format (.qtz suffix) as default, 
then we'll get *all* qtractor project stuff under the nominated NSM 
session directory tree (already compressed into one single archive/zip 
file, though)

perhaps, automatic symlinking of all the external files could be also 
doable at the NSM-Save instant, 'coz qtractor state is, among other 
important things, an inventory map of all those files anyway--some 
invasive coding required, though ;)

looks like, after all, that qtractor could stand compliant to both NSM 
levels 0 and 1+, in one fine blow, only if those file menu restrictions 
get subverted or just plainly ignored:o) and all the code to comply with 
the basic NSM API announce, open, save, close... gets eventually coded 
in, of course

aha. this seems the case for "edgy" applications like qtractor, when 
their own file new, open, save, and save as... menu operations are made 
completely orthogonal and independent of any general SM open/save ones.

try that with the not-so-edgy (mainstream?) applications ;)

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc at rncbc.org