[LAD] LADI

alex stone compose59 at gmail.com
Tue Dec 22 12:29:54 UTC 2009


On Tue, Dec 22, 2009 at 12:13 PM, Gabriel M. Beddingfield
<gabriel at teuton.org> wrote:
>
>
> 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.

But this doesn't happen. Jacksession saves the project state. So the
project entitled "my twiddles with my big piano" is saved, not a
repetitive copy of each patch. Patched are loaded in the sampler,
once. the sampler state is saved for that project, and when you reopen
that session, Gigasampler loads the "same" patch for the session as
you requested as saved previously. Sampled patches usually reside on a
static drive, and are "called" for when required. The same is not only
true for Gigasampler, but linuxsampler, kontakt, and most samplers.
They "request" the sample set, i.e. GIG. NKI. SFZ. Other, and it is
made available to the app. One sample library, accessible by request.

Same patch, same app, loaded as required, not saved everytime as a new
patch, i,e, big piano 1, big piano 2 ,etc...

the sampler data, i.e. "when this session is opened, load this patch"
is saved, only.

The same would be true for most apps in a jacksession, with the
exception of recorded audio sessions, and tell me a smart studio, or
serious audio engineer, that doesn't make multiple copies of recorded
sessions, with the view that a messed up session can be discarded, and
the engineer can go back to the previously saved set.

Even for domestic audio users, who don't want to back everything up,
and simply overwrite the previously saved session, most of their
session data is going to be saving "data states", and the overwrite
will imprint the new saved session over the old. Not the way i would
work, but it does work for others, who are quite happy to keep one
session.

Alex.




>
> -gabriel
>
>



-- 
www.openoctave.org

midi-subscribe at openoctave.org
development-subscribe at openoctave.org



More information about the Linux-audio-dev mailing list