On 04/03/2012 11:38 AM, rosea.grammostola wrote:
> 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).
* not the primary reason for this choice
>
>>
>> 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:03 2012
This archive was generated by hypermail 2.1.8 : Tue Apr 03 2012 - 12:15:03 EEST