[LAD] LADI

Patrick Shirkey pshirkey at boosthardware.com
Mon Dec 21 09:34:34 UTC 2009


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





More information about the Linux-audio-dev mailing list