21 Dec
2009
21 Dec
'09
5:22 a.m.
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
<pshirkey(a)boosthardware.com> wrote:
On 12/21/2009 10:18 AM, torbenh wrote:
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
On Sun, Dec 20, 2009 at 09:11:04PM +0100, rosea
grammostola wrote:
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
torbenh wrote:
session management ?
load/save of whole jack graph .
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.
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.