[LAD] LADI

[Gabriel M. Beddingfield]

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