linuxaudio.org

On Thu, Mar 29, 2012 at 4:40 PM, David Robillard  wrote:

quoted text
> On Thu, 2012-03-29 at 22:23 +0100, Rui Nuno Capela wrote:

>> 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...

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.

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev