Re: [LAD] LADI

You have no disagreement from me in any of the points you've made.

Alex.

On Mon, Dec 21, 2009 at 9:34 AM, Patrick Shirkey
<pshirkey@email-addr-hidden> wrote:
>
> On 12/21/2009 08:22 PM, alex stone wrote:
>> This is probably because the Jacksession version would need to
>> maintained in a seperate branch, and so we'd have 3 versions of jack
>> to deal with.
>> I tested jacksession, and it works well. (Using the experimental branch)
>> As Torben says, there's minimal intrusion in apps, and importantly
>> minimal change to the jack API.
>>
>> I'm sorry to see it stop, but Torben's been driving this forward, as a
>> practical opportunity for users, and not just a lot of discussion, and
>> if he feels the politics (and i think that is what's at the heart of
>> this) of doing this outweighs the positive benefits, then i can hardly
>> blame him for freezing it indefinitely or otherwise. Why keep bashing
>> your head against the wall?
>> If he decides to pick this up again, and take it further, then i'm
>> willing to continue testing, as i see jacksession as the simplest,
>> most elegant, and least intrusive session management system i've seen
>> to date. That's i guess, the best we can do for now.
>>
>> The users will have to wait, find another way, or just accept it's not
>> going to happen.
>>
>>
>
>
> I haven't seen anything on the lists that implied or suggested that
> jack_session would not be applied to Trunk once it was decided it was
> ready for wider testing.
>
> I have been expecting that to happen and am quite surprised that Torben
> has decided to freeze development. Is there some debate on irc that I
> have missed in the past two weeks?
>
> Just cos one person has strongly objected to it doesn't mean it
> shouldn't be made an optional feature for the rest of us to have access
> to. It can always be disabled at compile time.
>
> It doesn't add  bloat, it can be integrated with LADI, it is just a few
> additional callbacks, it's simple to integrate and it enables at least
> 80% of functionality for a normal users session management requirements.
> I would like to find out if it the remaining 20% is even needed by the
> majority of users.
>
> IIUC the current implementation is only missing support for undo. There
> are a couple of proposed options for the other issue of handling
> application naming conflicts. Any one of those options if implmented
> will be better than we have now.
>
>
>
>
>
> Patrick Shirkey
> Boost Hardware Ltd
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>

-- 
www.openoctave.org
midi-subscribe@email-addr-hidden
development-subscribe@email-addr-hidden
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev