On Mon, Mar 26, 2012 at 2:40 PM, Fons Adriaensen <[email protected]>wrote:
> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
