27 Mar
2012
27 Mar
'12
9:41 p.m.
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.
My POV about 'external' data (that is data not saved as part of
a session) is that if the user (or an app on behalf of the user)
declares that some data is external to the session then the SM
should just accept this as a fact an go on doing its thing. It
is then of course the user's responsability to take care of such
data if a session is transferred or archived.
I would expect a SM to have a tool to 'ls' a session (providing
a list of required apps etc.), and ideally such a tool should be
able to mention any dependencies on external data.
Using symlinks is indeed a simple solution, at least on Unixy
systems. It provides the required functionality, archiving tools
usually can be told to follow symlinks or not, and to the SM any
symlink in a session directory is an indication of 'external'
dependencies. And it doesn't require any extensions to the SM
protocol - creating a symlink is a declaration of external data.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)