Re: [LAD] LADI

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
Received on Mon Dec 21 12:15:02 2009