[LAD] NSM - handling large files

[Rui Nuno Capela]

On 04/03/2012 01:55 PM, rosea.grammostola wrote:
> On 04/03/2012 11:51 AM, rncbc wrote:
>> On 03.04.2012 10:38, rosea.grammostola wrote:
>>> On 04/03/2012 10:05 AM, rncbc wrote:
>>>> On 03.04.2012 06:49, Joel Roth wrote:
>>>>> On Thu, Mar 29, 2012 at 03:44:17PM +0200, 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 ?
>>>>>
>>>> <snip>
>>>>>
>>>>> As I understand it, the primary motivation for a session
>>>>> manager is to be able to save and restore the state of an
>>>>> audio project[1] that consists of multiple interconnected
>>>>> programs running on a multiprocessing Linux system.
>>>>>
>>>>> In other words, the minimum capability sufficient to be
>>>>> useful would be some sort of checkpointing mechanism.
>>>>>
>>>>> A secondary goal, discussed extensively here, is that it
>>>>> would be nice to be able to copy a session or export a
>>>>> session. This is where all the contentious issues with
>>>>> handling filesystem objects comes up.
>>>>>
>>>>> The latter goal should be optional, IMO, rather than required.
>>>>>
>>>> </snip>
>>>>
>>>> this is exactly what i've been trying to tell (only that my english
>>>> wording leaves a lot to be desired)
>>>>
>>>> thanks Joel :)
>>>>
>>>> the primary goal is already achieved by qtractor on jack-session and
>>>> ladish; the second goal is the one i called "utopian".
>>>
>>> As far as I understood, to have everything saved in the session
>>> folder was designed to make the behavior of the session manager more
>>> predictable and more simple to avoid errors and misbehavior.
>>> To be able to export the session was *not* the primary choice for
>>> this (correct me if I am wrong).
>>>
>>
>> but is this one i complain about. nb. getting the full application state
>> saved under one SM session directory is a lot different than saving
>> everything an application state refers to under the same SM session
>> directory.
>>
>> i'll gently recall you can actually have sort of both with qtractor
>> under jack-session management: you just choose which of qtractor's
>> default session file format you want: either the regular xml state file
>> (.qtr) or the complete bundle, self-contained archive/zip file (.qtz).
>> note that if your files are huge, saving in this latter format might
>> just take more time :)
>>
>> however, please note, that's just a qtractor's user
>> preference/convenience option, not mandated by any permanent rule of the
>> SM API.
>
> But Qtractor seems to be special case here. Jonathan said in this thread
> that there are not many apps with the same behavior when it comes to
> saving and using files/ sessions.
>
> So saying that this isn't ideal for Qtractor-like-applications, doesn't
> say that other developers have problems with the strict saving rules of
> NSM.
> (I have the *feeling* that these rules are in general harder to accept
> for developers of big applications like Qtractor, Ardour, Muse etc, then
> it is for small applications. The first have the unconscious urge of
> being in charge I can imagine, but I could be wrong).
>

speaking of which

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.

my feeling again is that the effort to comply with NSM isn't, won't be 
so easy for any lass-than-simple-textbook-like client examples

once again, i call for some ardour expertise. i'm even afraid to ask 
this btw, but does ardour work with jack-session already? o.O

aham

> However, it might be fair to take a look at how JackSession does this
> and answer the question why it is or why it is not a problem to not have
> these saving restrictions.
>

jack-session has some fsck-up restrictions of its own

one that i had historical complaints is about this non-reusable session 
directory restriction (here, the "non" particle, is not a pun;) which 
meant that you can't save into the same session directory twice

a "really-smart/intelligent" SM could copy and re(sym)link all the 
references under each client participant's session sub-directory, yes, a 
chimeric kind of effort comes to mind :o)

alas. this jack-session restriction has been somewhat circumvented by 
the "versioning" feature on qjackctl-as-jack-session-manager, by yours 
truly. yes it's true, but it shows you how cumbersome is like when one 
has to go around and break the red tape of those draconian SM's ;)

and now NSM is about asking for even more and thicker red tape...

cough

now, i could suggest NSM API to be split in levels of compliance and 
restrictiveness, so to speak:

- level 0 :- clients just store/retrieve their own private state from a 
supplied and independent session sub-directory; no GUI File menu 
restrictions; no file location restrictions, no symlinks, no juggling, 
no dupes, no sh*t.

- level 1+ :- anything that (may progressively?) imposes each one the 
mentioned non-restrictions of level 0.

starting with level 0, there's a fair chance for NSM to revolve, and 
even co-exist peacefully with jack-session and ladish. call me a dreamer :)

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