18 May
2009
18 May
'09
12:37 p.m.
Marc,
Thanks, and a great user oriented explanation.
I'm also mindful of the considerable work being done with the LADI
tools, and the testing i enjoyed doing last year.
Just to be clear here, i still can't see the need for an additional
layer of 'complication' (don't forget i'm just a user, not a coder.),
but i'll continue to be open minded about the progress. The old Jackd
is definitely my comfort zone, and it would true to say, that anything
that upsets that stability starts me asking questions.
Thanks again, i just learned something, whether i agree with it
currently, or not.
Alex.
On Mon, May 18, 2009 at 6:25 PM, MarcO'Chapeau <marco(a)marcochapeau.org> wrote:
On Mon, 18 May 2009 17:36:11 +0400, alex stone
<compose59(a)gmail.com> wrote:
--
Parchment Studios (It started as a joke...)
Marc,
hehe, and the waltz continues. So let's assume that pulse isn't being
considered here as part of the dbus paradigm intent .
Hi again.
Ok, let's stop dancing then :) Let me try to explain that dbus here is not
the center of what has changed in JACK2.
The new feature in JACK2 is the control API. That is: a *C control API*.
Now it is very important to read the previous sentence over and over again.
Once the dbus keyword has disappeared of your focus, read on.
So, this C/C++ control API allows one to start/stop jack, configure it, and
manage connections in between clients. This C control API allows one to
control the server entirely in a cleaner fashion than what was used before.
jackd makes use of this new API.
And now the fun part. Say we want to control JACK with hmm... OSC. One will
program something called jackosc that will *expose* the jack control API
through a small OSC server. it's as simple as some python bindings for
instance.
Now that I have explained most of the new stuff in JACK2, back to our
issue. jackdbus is just like what I described with jackosc, except that
instead of *exposing the C API* through an OSC interface, we do that
through a DBUS interface.
Is there going to be a non dbus jack version
going forward?
You should already have the answer : there is and there will always
be. The
JACK control API is the core and is C, dbus is just an interface, just like
any other kind of interface would be (OSC, HTTP, whatever...).
And please assume here i'm talking about a
complete
non dbus version, not a compile time option to disable it.
So you want to have 2
separate versions maintained ? One with a control API
and no interfaces other than plain C and one with interfaces included ?
Because if it's not a compile time option, I don't see what else it could
be.
Who wants to maintain to trees just to hide a compile time option ? what if
we really add jackosc to the list ? Should that be a third tree ?
Nedko, Stéphane: If I made any mistakes in my explanations, please correct
me :)
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user