On Tue, 22 Dec 2009, alex stone wrote:
> This is a bit disingenuous to use as an example.
Not quite:
1. I was actually thinking of the database used
by _Audacity_ to store data. For some reason
I thought it was Ardour doing that. So,
s/Ardour/Audacity/g if you like. But it still
stands for Ardour because of the size of the
data and the fact that it has save states
(snapshots) but no Save-As.
2. I was thinking of my own, future, application
where I'm seriously considering having all
audio resources (for all sessions and
compositions) in a single, managed database...
similar to Git (as was stated in the link).
3. In my day job, I work extensively with 3D CAD
models for mechanical engineering, where you
have hundreds of files with implied relationships
between them (parts, assemblies, drawings). It's
a fragile mess that requires a managed database
to keep straight.
And I'm not Not NOT using the example to say "session
management is junk" OR to be combative. I'm thinking
through the case where session data is large and what that
means with a session data directory.
> 2.) you assume it's either/or based on your ardour example for "heavy"
> or "light". Again, this is based on an app where the session, once
> created, cannot be moved, and can, at best, only be linked to. Save as
I'm talking about what happens when the data set for
the session is very large. It's going to happen, and people
are going to try and speed it up and conserve disk space.
What about the case where someone wants to save their
session that uses that 1 GB piano patch (gigasampler)? If
it's part of the session... should the whole patch be copied
to the session directory or not? If that's your favorite
patch, that's a lot of copies.
-gabriel
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Dec 22 16:15:02 2009
This archive was generated by hypermail 2.1.8 : Tue Dec 22 2009 - 16:15:02 EET