3 Apr
2012
3 Apr
'12
12:55 p.m.
On 03.04.2012 10:38, rosea.grammostola wrote:
On 04/03/2012 10:05 AM, rncbc wrote:
but is this one i complain about. nb. getting the full application
state saved under one SM session directory is a lot different than
saving everything an application state refers to under the same SM
session directory.
i'll gently recall you can actually have sort of both with qtractor
under jack-session management: you just choose which of qtractor's
default session file format you want: either the regular xml state file
(.qtr) or the complete bundle, self-contained archive/zip file (.qtz).
note that if your files are huge, saving in this latter format might
just take more time :)
however, please note, that's just a qtractor's user
preference/convenience option, not mandated by any permanent rule of the
SM API.
byee
--
rncbc aka Rui Nuno Capela
On 03.04.2012 06:49, Joel Roth wrote:
As far as I understood, to have everything saved in the session
folder was designed to make the behavior of the session manager more
predictable and more simple to avoid errors and misbehavior.
To be able to export the session was *not* the primary choice for
this (correct me if I am wrong).
On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel
Rumpf wrote:
<snip>
Back to life - back to reality
1. We start qtractor as part of a session, create some
midi-tracks,
include some external wav-files.
Should the SM "know" about these external files, as I suggested ?
(Allowing the user to find out basic info about it. )
Or leave it completely to qtractor ?
As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.
In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.
A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up.
The latter goal should be optional, IMO, rather than required.
</snip>
this is exactly what i've been trying to tell (only that my english
wording leaves a lot to be desired)
thanks Joel :)
the primary goal is already achieved by qtractor on jack-session and
ladish; the second goal is the one i called "utopian".