Re: [LAD] Non Session Management

On Tue, Mar 27, 2012 at 07:41:27PM +0000, Fons Adriaensen wrote:
> On Mon, Mar 26, 2012 at 05:15:09PM -0700, J. Liles wrote:
>
> > Fons, I'd like to hear more about this use case. 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. But as far as sharing heavy state
> > between multiple clients in a session, I have not considered the issue. It
> > is certainly possible to permit something like that, and even as it is
> > right now two clients could work something out peer-to-peer using the NSM
> > server's 'broadcast' capability. If several different sessions need to
> > share the same data, then I would say that it's reasonable just to have it
> > stored outside of the session root, preferrably symlinked from within the
> > session so that it could be picked up by a simple archiving process.
>
> You may have misread what I wrote, it's not about data shared
> between clients in a single session (but that is an interesting
> twist that I havent' considered so far). It's a about essentially
> read-only and possibly huge data sets shared between sessions.
>
> Given a multitrack recording, I may be required to make a 3rd
> order Ambisonic mix originally, another for some discrete speaker
> set used at a concert some months later, and a Wave Field Synthesis
> one at any time. They all use the same recorded and edited tracks,
> but the tools and methods used are completely different in each
> case, and I would really not want to combine them into a single
> session. If only because someone using any of these forms should
> not be required to have the tools for all the other ones. Nor
> would I want the the shared data to be duplicated - not only
> because it's a wast of disk space, but also because it may be
> reviewed and modified as well (e.g. correcting bad edits) and
> such changes should be picked up by all sessions using the data.

So the shared data would not be read-only after all...
Isn't this a little bit dangerous?
I can see this could work with certain kinds of apps
that are non-destructive. But how do you know that
doing edits to the data in one session doesn't make
the other invalid. In other words, how can you control
such a thing without duplicating data?

lieven
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Mar 28 12:15:03 2012