3 Apr
2012
3 Apr
'12
4:21 p.m.
Am 3. April 2012 05:49 schrieb Joel Roth <joelz(a)pobox.com>om>:
(gaol one)
As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.
In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.
A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up.
We have two gaols, as Joel told us.
goal 1. store/restore - is already reached by NSM, if you ask me
goal 2. archive/copy/duplicate - is the point of this discussion
with goal 1. only
we have a session manager, that can handle projects you are currently
working on,
but if you want to, or have to, transfer the session to a different machine,
if you re-install your system, if you intent to store a sessions data,
if any data has to be moved, then -- your sessions are
very much lost -- as far as I can tell
As an NSM-client, you do what you want with the data, thus
nobody knows, how to automatically or manually fix lost path information,
how to ensure things are stored properly, etc...
with goal 2.
which could - at least to a very basic degree - be reached,
by forcing symlinks, there would be a tiny base, for further improvements
and dedicated helper scripts in the future
--
E.R.