linuxaudio.org

On 12/21/2009 08:22 PM, alex stone wrote:

quoted text
> 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@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev