Re: [LAD] Non Session Management

On Mon, Mar 26, 2012 at 2:40 PM, Fons Adriaensen <fons@email-addr-hiddenwrote:

> On Mon, Mar 26, 2012 at 10:32:38PM +0200, Emanuel Rumpf wrote:
>
> > - where would audio apps store large (audio) files ? a custom path ?
>
> That is something that needs to be looked at.
>
> In my use cases it is very common for several projects to use
> the same recorded tracks, and that could be a few gigabytes.
> When using non-destructive editing these are de facto read-only,
> so they can be shared.
>
> An app can always cheat the SM. Even if the SM forbids symbolic
> links in a session directory, all it takes for an app is saving
> a directory path as part of the current configuration.
>
> But it would be better if the SM were aware of the existence
> of such data, so that it could e.g. show of list of it upon
> request. This would then require apps to explicitly declare
> paths to external data. It would probably be a rather simple
> extension to NSM.
>
>
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.

Perhaps someone in a situation like this might also consider using some
kind of deduplicating filesystem to store their data and remove the
complexity to the systems level.

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Mar 27 04:15:06 2012