30 Mar
2012
30 Mar
'12
3:29 a.m.
On Thu, Mar 29, 2012 at 4:40 PM, David Robillard <d(a)drobilla.net> wrote:
On Thu, 2012-03-29 at 22:23 +0100, Rui Nuno Capela
wrote:
I absolutely agree on this point. In fact, referring to external files
in this way is now on my TODO list for Non-DAW.
Currently, when you drag n' drop an external audio file into a Non-DAW
timeline (as opposed to recording it from within Non-DAW), the file
remains external with its path recorded
in the project's journal. Using a symlink for this would be better in
*at least* the following two ways:
1) Allows archiving scripts etc. to discover and import the external
source *without having to understand the Non-DAW journal format*
2) It would allow Non-DAW to import external sources *without having
to update (or break) any existing references*
I cannot imagine any argument that could propose that these are bad things.
If all Linux Audio software dealt with external references in this
way, archiving/export would be much less problematic.
However, I would also like to offer an interesting little statistic...
I, personally, have hundreds of projects representing terabytes of
data, and in all that I don't have a single project which refers to
anything external to its project directory. This is something that
only effects certain users who make extensive use of sound-clip or
sample libraries. Not people who just do plain old
recording/synthesis/mixing. So let's try not to make a mountain out of
a mole hill. What is the actual percentage of users who have
references to external files *and* a strong need to export their
sessions? I suspect that it is in fact a very low number.
Furthermore, in addition to the plain old symlinks, a truly robust
solution might also store e.g. SHA1 hashes of external files, so that
any mismatch is detectable.
now back to square one. to make that whole
session state, folder or
directory, as an archival portable one is, quite frankly and imho again,
utopian. nuff said :)
It's indeed utopian to think that some centralized special magic program
and protocol and file format and whatever else will actually get
universally adopted.
However, files and directories and links are anything but
unrealistically utopian. That's my point.
With all due respect, Emanuel, you can see here what happens when you
make a big complicated mess out of things and try to ram technology down
implementer's throats without justification: they simply reject it
outright as a utopian fantasy.
Achieving archival/etc is *trivial* without any fancy/annoying session
management crap whatsoever. If apps want to save in a way that prevents
it, they will always be able to, however if they do, there is *one*
simple rule that makes *all* the mentioned functionality possible that
has nothing to do with any specific session manager API/protocol/file
formats/etc whatsoever:
* All references to files outside the session directory must be a
symlink to that file
That's it. No APIS, no protocols, no session manager file stores, no
redundant data that may not match reality, no egregious rules. There's
not even a requirement for a session manager to be involved whatsoever,
if an app saves this way independently you can archive its sessions with
tar or whatever just the same. If you did want a fancy GUI archival
tool that reports what files are used and whatever else, you could write
one, and it wouldn't even depend on the session manager at all - and I
don't mean it would loosely depend on it by only using OSC or whatever,
I mean it would not depend on it *at all*, nor would it depend on any
file format[1]. All even vaguely common languages have everything
required in their standard library, right now. All of that Just
Works-eyness is because it's a simple idea, and doesn't use anything
that hasn't been baked in to the OS for literally decades. It doesn't
get much less unrealistically utopian than this.
Erecting some fantastic non-existent architecture to achieve, in one
special circumstance, what this simple rule does, is a folly doomed for
failure. To really distill it down, since we're on a "reality" trip:
you can either try to get people to adopt this convention, or you can
not have archivable/distributable sessions. There is no option C.
That said, if I'm overlooking something, do tell (i.e. why, exactly, is
this simple plan not sufficient?), because from where I'm standing it's
a real mystery why we are acting like this is so damned complicated.
It's not. At all.
-dr
[1] Try to sell any file format to this crowd and see how far you get...