On Tue, Dec 22, 2009 at 12:13 PM, Gabriel M. Beddingfield <[email protected]> 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 [email protected] [email protected] _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
