On 04/03/2012 10:05 AM, rncbc wrote:
> 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).
>
> speaking from a developer's pov. i find it very unlikely that NSM will
> ever get broader acceptance than jack-session and/or ladish, given the
> "utopian" restrictions it poses on client application design.
>
> i wonder for a while: modifying an application to participate in
> jack-session, for instance, is dead simple and costs only a small amount
> of developer time and effort, provided he/she has the proper motivation ;)
>
> otoh. i have this creepy feeling that, to comply to NSM, one has to
> compromise a lot of the application design and behavior--gui
> restrictions, file location restrictions, osc managing interface, to
> name a few--not that they are bad ideas at all, quite the contrary, but
> they impose a kind of non-negligible (pun intended;) change into
> application workings, unless coded to comply to the NSM-client-logo from
> day zero.
Feelings are important, especially when dealing with something like
session management which success depends more or less by the adoption by
others. But I think we need to know the *facts* here. Is it really that
way as you think it is, or is it just your initial resistance (which one
can understand) to comply to the strict rules of NSM and isn't it that
bad when having a closer look at it?
It's a reasonable point to discuss though...
>
> i keep wondering: if that ever flies above its toes then i'll certainly
> call it "The linux-audio revolution" (or miracle, scnr:)
>
> cheers
> --
> rncbc aka Rui Nuno Capela
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Apr 3 12:15:02 2012
This archive was generated by hypermail 2.1.8 : Tue Apr 03 2012 - 12:15:03 EEST