3 Apr
2012
3 Apr
'12
3:35 p.m.
On 04/03/2012 02:55 PM, rosea.grammostola wrote:
On 04/03/2012 11:51 AM, rncbc wrote:
When searching for an answer, you find at least two quotes which tell
you that it is important:
[Quote=Fons]
3. Clearly defining the way an app should behave w.r.t. its
File menu entries (when managed). This is quite intrusive
to existing clients, but it is IMHO absolutley essential.
Kudos to the designer(s) for the having the courage to do
this instead of allowing application developers to take
the 'least effort' way (which would of course be better
marketing, but invite later misery).
[/Quote=Fons]
*Why* this is essential isn't elaborated by Fons though.
[quote=Liles]
Currently one of the strong points of NSM is that applications with
heavy state (e.g. large audio files) know *exactly* where to put the
state at the time they join the session. This eliminates the need for
undesirable hacks with just storing a link to the heavy state (as was
generally required with LASH). I felt like this was one of the primary
requirements of Non-DAW which was not addressed by other session managers.
[/quote=Liles]
(Assuming that this ^ is because of the strict opening and saving rules
of NSM).
Liles compares here with LASH, undesirable hacks are not needed anymore.
Why is this a primary requirement?
Moreover LASH isn't seen as a serious candidate anyway these days. I
would rather see a comparison with JackSession in this area. In other words:
How JackSession does this and why is it, or why it is not, a problem to
not have these strict rules for applications which are in a session.
Regards,
\r
On 03.04.2012 10:38, rosea.grammostola wrote:
But Qtractor seems to be special case here. Jonathan said in this thread
that there are not many apps with the same behavior when it comes to
saving and using files/ sessions.
So saying that this isn't ideal for Qtractor-like-applications, doesn't
say that other developers have problems with the strict saving rules of
NSM.
(I have the *feeling* that these rules are in general harder to accept
for developers of big applications like Qtractor, Ardour, Muse etc, then
it is for small applications. The first have the unconscious urge of
being in charge I can imagine, but I could be wrong).
However, it might be fair to take a look at how JackSession does this
and answer the question why it is or why it is not a problem to not have
these saving restrictions. 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. On 03.04.2012 06:49, Joel Roth wrote:
> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>
>> 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 ?
>
<snip>
>
> 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".
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).