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 <[email protected]> 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 > [email protected] > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > -- www.openoctave.org [email protected] [email protected] _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
