21 Dec
2009
21 Dec
'09
6:45 a.m.
torbenh wrote:
On Sun, Dec 20, 2009 at 09:11:04PM +0100, rosea
grammostola wrote:
@Torben, thanks for your answer. It seems one side effect of becoming a
session handler programmer, is getting a lot of debate. But this is
maybe not unexpected, cause it 'hits' the whole community. Also history
has shown that it will take at least some time to implement a session
handler. So maybe it's not realistic to expect consensus in a relative
short period.
Anyway, to get a more clear picture of the situation, I think it's good
to know what the opinions are from the (former) LASH maintainers. So
@Bob Ham, David Robillard and Juuso Alasuutari,
Can you describe in your own words:
1) What are the strong and weak points of LADI in your opinion and why?
2) What will be a good approach now for getting a Linux audio session
handler in your opinion
(taking also LASH/LADI/Jack Session and Fons ideas in account)?
3) Are you willing to contribute to an solution and how do you see this
(own project / collaboration with other projects etc.).
Please try to keep it short and to the point.
Thanks in advance,
\r
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.