22 Dec
2009
22 Dec
'09
8:29 a.m.
On Tue, Dec 22, 2009 at 12:13 PM, Gabriel M. Beddingfield
<gabriel(a)teuton.org> wrote:
On Tue, 22 Dec 2009, alex stone wrote:
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.
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
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org