<br><br><div class="gmail_quote">On Mon, Mar 26, 2012 at 2:40 PM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@linuxaudio.org">fons@linuxaudio.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Mar 26, 2012 at 10:32:38PM +0200, Emanuel Rumpf wrote:<br>
<br>
> - where would audio apps store large (audio) files ? a custom path ?<br>
<br>
</div>That is something that needs to be looked at.<br>
<br>
In my use cases it is very common for several projects to use<br>
the same recorded tracks, and that could be a few gigabytes.<br>
When using non-destructive editing these are de facto read-only,<br>
so they can be shared.<br>
<br>
An app can always cheat the SM. Even if the SM forbids symbolic<br>
links in a session directory, all it takes for an app is saving<br>
a directory path as part of the current configuration.<br>
<br>
But it would be better if the SM were aware of the existence<br>
of such data, so that it could e.g. show of list of it upon<br>
request. This would then require apps to explicitly declare<br>
paths to external data. It would probably be a rather simple<br>
extension to NSM.<br>
<div class="im HOEnZb"><br></div></blockquote><div><br>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. <br>
<br>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.<br><br><br><br><br> <br></div></div>