On Tue, 19 May 2009 10:38:24 +0200, Stéphane Letz <[email protected]> wrote: > 4) A possible proposed solution was to define 2 completely separated > packages for jack2 : the "classic" one would package the "jackd" > incarnation and allow Qjackctl and legacy control applications to be > used with it. The "D-Bus" one would package the "jackdbus" > incarnation, and provide D-Bus bas control applications (patchage, > ladi tools....). The problem of this strategy is that..., it is a kind > of complete failure regarding the way jack is supposed to be > distributed. It may even get worse if a new "jackosc" incarnation (a > one that would allow to control the server using OSC) appears a some > point in the future...
And we will all agree that this would be a packaging disaster. I package jack for gentoo pro-audio, and I really don't know how I'd handle this one. > 5) Another idea would be improve the "choice of auto-start strategy" > by providing a runtime choice for that: a way for the user to select > between the "classic", "D-Bus", "OSC", strategy once globally for a > given working session... To me, this one is the cleanest of all, and would allow to keep auto-start for those who like it with the flavor of their choice (and eventually disable it for those who don't ?) > 5) Another idea would be be to completely drops the "auto-start" > strategy...This way we don't have multiple strategy anymore, and solve > most of the problems... but loose a feature. Last resort but if it comes down to this, I can handle my idea of auto-start directly inside LADITools using dbus calls. although it wouldn't be as good as the "any client can auto-start jack" paradigm. Marc-Olivier Barre. ------ Participez au black-out anti-HADOPI : http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
