21 Dec
2009
21 Dec
'09
7:07 a.m.
Why not both?
Use either/or compile options:
--enable-jacksession
--enable-dbus
The bit you forgot to mention is the lack of network session
capability using your dbus method. It's still not suitable for
clusters.
However Bob Ham, in an earlier post, explained this far better than i
could, so reading up will bear fruit. He also eloquently highlighted
the rapidly ensuing complexity of having to run multiple dbusses in
some fashion to counter the limitations dbus has in providing cluster
support.
Far too complex, imho, compared to the simplicity, and minimal impact,
jacksession has on the API. Torben has already proved this
emphatically, imho, and as a user tester i found it SIMPLE and easy to
use. Surely a criteria for any developer to consider.
Add to that the ease at which he sessionised apps, with a few lines of
code, compared with the wholesale reconstruction required by lash, for
instance, and he makes a powerful and compelling case for jacksession
as a modest additional component in the API. (imho)
Jacksession, as a component, was accused of being insufficient,
therefore dismissed out of hand, for being "80%". The situation is no
better with a dbus version, and likely other constructs too.
So lets compare apples with apples here, if only for fair assessment.
Alex.
On Mon, Dec 21, 2009 at 10:33 AM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
Patrick Shirkey <pshirkey(a)boosthardware.com>
writes:
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
From a normal users perspective we would need to
have an interface that
gave us the options:
- killing already running apps before loading a session
- attempting to rename the apps without restarting them
- load a new jack instance and connect it with netjack
I don't get why these features are supposed to need support from jack
itself. Session handler/manager starts the apps and it for sure knows
how to kill them (ladishd does this already). Renaming of the clients is
not needed for ladish to operate, because ladishd implements graph
virtualization and boxes you see on canvas (clients) can be renamed and
ports can be regrouped. For handling apps that use multiple JACK
clients, more useful will be to have a function that returns the
originally requested JACK client name. netjack has two main uses
(Internet and LAN) but I don't see how jack session callbacks relate to
it. ladish-2.0 (multihost capable) will be able to start additional jack
servers, local or remote and use netjack tehcnology to link them in
single multihost studio.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev