Re: [LAD] NSM - handling large files

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@email-addr-hidden
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev