Rui Nuno Capela rncbc at rncbc.org
Sat Nov 21 15:36:56 UTC 2009

On 11/21/2009 02:47 PM, Patrick Shirkey wrote:
> On 11/21/2009 10:13 PM, Rui Nuno Capela wrote:
>> On 11/21/2009 05:18 AM, Patrick Shirkey wrote:
>>> One major item of note is that qjackctl now has preliminary dbus support
>>> even though Rui has stated that it would not happen. This step in itself
>>> should be clear a major roadblock to LADI integration and deployment.
>> wait, i don't seem to remember having said it would *not* happen. i
>> think i had said it would be *hard* to happen, mainly due to my
>> everlasting lack of time. you all know the stance ;)
>> and moving on a bit (but staying in the same place):
>> i think a also made my position long ago that qjackctl is a jack control
>> application and thus, it should harness the jack control api and nothing
>> else on the side. imo, it's this jack control api or protocol that
>> should be implemented through whatever ipc mechanism you think of (dbus,
>> osc, yada yada).
>> ok, in that sense, you can say that qackctl would not go the jack dbus
>> route, at least directly face to face. again imo, it must do it on top a
>> an established jack control interface. no more no less ;)
> LADI represents a very powerful and flexible session management system 
> that has been built on 7 years of intense debate/thinking/development 
> and several competing and complimentary implementations.

first time i've heard of the ladi effort was in the lac2007 at koln
cafeteria. is there an old conspiracy or has dan brown already picked up
the lads as subjects?  nevermind, i've been m.i.a. too many times :)

> Qjackctl *is* the default desktop management interface for jack.
> It would be a very powerful combination if qjackctl supported the 
> functionality provided by the LADI tools. Currently we have a 
> chicken/egg situation as you are not prepared to spend your valuable 
> time on session support until it is officially established but if the 
> default management tool doesn't support the most flexible option we have 
> available then how can it be considered established?

please note, i've meant the establishment of the so called *jack control
api* iow, libjackcontrol.so.

i really don't care whether that jack-control-api is actually
implemented through dbus, osc or whatever-ipc, but it must be
established enough as the official way to control jack. qjackctl, as i
know it, is only going through that jack-control-api and *not* dbus,
osc, whatever.

> If LADI which now represents a significant effort by several very clever 
> and committed developers is not officially supported then we as a 
> community are encouraging the fragmentation to continue rather than 
> forging better integration.
> Supporting LADI doesn't mean that a non dbus solution can't be supported 
> or that everyone has to be forced to use the dbus solution.

of course.

rncbc aka Rui Nuno Capela
rncbc at rncbc.org

More information about the Linux-audio-dev mailing list