linuxaudio.org

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.
Alex.
On Mon, Dec 21, 2009 at 8:54 AM, Patrick Shirkey

 wrote:

quoted text
>

> On 12/21/2009 10:18 AM, torbenh wrote:

>> On Sun, Dec 20, 2009 at 09:11:04PM +0100, rosea grammostola wrote:

>>

>>> torbenh wrote:

>>>

>>>> On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea grammostola wrote:

>>>>

>>>>> What can we expect from group 2? Maybe some of the lash developers

>>>>> belongs in this group?

>>>>> Dave, Juuso, Bob Ham, ... ? What are your plans now?

>>>>>

>>>>>

>>>> dunno... jack session is frozen now.

>>>>

>>>>

>>> Torben, thanks for your reply.

>>>

>>> Can you, for the people who didn't follow the development of jack

>>> session, shortly point out what jack session does.

>>>

>>> 1) What do you want to achieve with jack session.

>>>

>> session management ?

>> load/save of whole jack graph .

>>

>>

>>> 2) How do you think you are able to achieve it?

>>>

>> with very few exceptions every app thats a target for session

>> management, is a jack client.

>> so why not add some callbacks, and let the sessionmanager

>> communicate with apps via jack ?

>>

>> this basically reduces the size of the app patches.

>> allowing me to patch at least one app per hour.

>>

>>

>>> 3) Why do you think this is the best way to do it?

>>>

>> every app is already using jack IPC to communicate with jackd.

>> ->  minimally invasive on the app.

>> no reinvention of the wheel or yet another IPC mechanism to add.

>>

>> anyways... effort is frozen.

>> we are dumping a working implementation.

>>

>>

>>

>

>

> I don't understand why you have made this decision.

>

> The basic framework that you have implemented will be very useful for a

> large subset of the requirements of a session management system. In may

> be more than enough for 95% of normal users to get things done.

>

> If people need to take things further they have the option of using LADI

> or waiting for Fon's to release his work.

>

> There was only one person who categorically said they wouldn't be able

> to work with your additions and he is already making his own system anyway.

>

> I would like to see your work included as an option as that would also

> give Nedko (and maybe even Fons) an opportunity to extend and integrate

> their efforts to work with yours.

>

> Wholesale writing off your efforts simple because the debate got heated

> seems unnecessary to me.

>

>

>

>

>

>

>

>

> 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

>

--

www.openoctave.org
midi-subscribe@openoctave.org

development-subscribe@openoctave.org

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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