Re: [LAD] NSM - handling large files

On Tue, Apr 3, 2012 at 6:35 AM, rosea.grammostola
<rosea.grammostola@email-addr-hidden> wrote:

> [quote=Liles]
> Currently one of the strong points of NSM is that applications with heavy
> state (e.g. large audio files) know *exactly* where to put the state at the
> time they join the session. This eliminates the need for undesirable hacks
> with just storing a link to the heavy state (as was generally required with
> LASH). I felt like this was one of the primary requirements of Non-DAW which
> was not addressed by other session managers.
> [/quote=Liles]
>
> (Assuming that this ^ is because of the strict opening and saving rules of
> NSM).
> Liles compares here with LASH, undesirable hacks are not needed anymore.
> Why is this a primary requirement?

Because LASH was designed with the assumption that all client
applications would either:

1) Store all their state in memory and be fine with just dumping it to
disk when the save yourself message came.
2) Naturally store their heavy state in some random place (like QTractor?)

Programs with heavy state closely associated to the individual
projects (like Non-DAW and Ardour) had to work around this by just
storing the project data in some random place and only storing a
reference to it in LASH, which was terrible from a consistency
perspective because the user really had no idea where their data was.

I want to have my sessions laid out on disk in a very specific way,
with none of them named after GUIDs, and no applications/data being
(mis)directed to a session just because it happened to be the last one
active.

With NSM (this is part of the server implementation and not the
protocol) the user can lay things out on disk however they like,
organizing their sessions in any way they want (including doing fancy
things with subdirectories and symlinks) *and* have an expectation
that e.g. the audio they record in Non-DAW after adding it as a client
to a session *actually goes into the session directory they defined
when they created the session*. If I want to back up my audio
partition, I should not have to track down gigabytes of data from
some hidden directory in $HOME that is only referred to inside
incomprehensible XML files as well.

The matter is complicated by applications which have been attempting
to do their own crude form of session management. But here's the key
point: It is only reasonable to expect an application to adhere to
*one* system of session management at a time. So, if the application
is connected to NSM, it should behave in a way consistent with other
NSM capable applications, and if it is connected to XSM, JackSession
or LASH, or what have you it can do whatever those systems allow
(which is totally undefined anyway).

> Moreover LASH isn't seen as a serious candidate anyway these days. I would
> rather see a comparison with JackSession in this area. In other words:
>
> How JackSession does this and why is it, or why it is not, a problem to not
> have these strict rules for applications which are in a session.

I believe JackSession was intended to be the bare minimum required to
transmit a 'save' message to JACK applications... Just a very basic
protocol. Doing anything more to ensure a smooth and consistent user
experience is outside of its scope. A lot of this behavior depends on
the implementation of the Session Manager server itself, but
JackSession by its nature has some basic limitations that exclude the
possibility of the kind of features NSM has, so a server
implementation for it can only do so much...
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Apr 3 20:15:02 2012