On Sun, 2009-05-17 at 13:11 +0200, Fons Adriaensen wrote:
> On Sun, May 17, 2009 at 12:20:34PM +0200, MarcO'Chapeau wrote:
>
> > - dbus is not the default compile time config option. Your distro should
> > probably disable it (until it's stable and shiny)
>
> On this I agree.
(sorry for the dela
On Tue, 2009-05-19 at 21:41 +0200, Fons Adriaensen wrote:
> On Tue, May 19, 2009 at 08:28:21PM +0100, Bob Ham wrote:
>
> > > Scroll back 100 messages, read everything and maybe
> > > you will grok it :-)
> >
> > I was reading through the thread when I encountered your fiction. It's
> > the previ
You get me wrong.
Patrick Shirkey wrote:
> Ralf.
>
> I find it hard to see how you actually understand Linux audio. I get
> the impression that you have almost tried but instead have
> persistently trolled on this point since you arrived.
>
> The above is a "full stop" of Ralfs dialog, I say thi
On Tue, May 19, 2009 at 08:28:21PM +0100, Bob Ham wrote:
> > Scroll back 100 messages, read everything and maybe
> > you will grok it :-)
>
> I was reading through the thread when I encountered your fiction. It's
> the previous messages that brought me to the conclusion I came to about
> the poi
On Tue, 2009-05-19 at 21:08 +0200, Fons Adriaensen wrote:
> On Tue, May 19, 2009 at 05:44:36PM +0100, Bob Ham wrote:
>
> > Such is the danger of analogies. What was the point?
>
> Scroll back 100 messages, read everything and maybe
> you will grok it :-)
I was reading through the thread when I
On Tue, May 19, 2009 at 05:44:36PM +0100, Bob Ham wrote:
> Such is the danger of analogies. What was the point?
Scroll back 100 messages, read everything and maybe
you will grok it :-)
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
Ralf.
I find it hard to see how you actually understand Linux audio. I get the
impression that you have almost tried but instead have persistently
trolled on this point since you arrived.
The above is a "full stop" of Ralfs dialog, I say this just in case
there is a possible alternative that s
On Tue, May 19, 2009 at 5:48 PM, Ralf Mardorf
wrote:
> The latest version of the Atari Cubase still can run sessions of the
> first version, sometimes you can't do this with Rosegarden between two
> versions
Quite off-topic, but I can't let this pass. Any release of Rosegarden
made in the last d
Nedko Arnaudov wrote:
> [snip] Or you blame gnome folks about new KDE being crap?
>
> :)
>
:D
I'm running KDE and GNOME and if there will be conflicts for KDE
applications, because of GNOME packages, the blame for an odd KDE might
be on GNOME and I blame Steinberg not to give a FLOSS Cubase
Bob Ham wrote:
> On Tue, 2009-05-19 at 18:27 +0200, Fons Adriaensen wrote:
>
>> On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham wrote:
>>
>>
>>> I have to say, I think this is really out of line, Fons. Implying free
>>> software developers are theives because they've changed something an
Ralf Mardorf writes:
> The latest version of the Atari Cubase still can run sessions of the
> first version, sometimes you can't do this with Rosegarden between two
> versions (okay, I nearly does NO RT-AUDIO with Linux ;)). But the
> point isn't what is possible or impossible for other OS's. For
Nedko Arnaudov wrote:
> Ralf Mardorf writes:
>
>
>> Nedko Arnaudov wrote:
>>
>>> Ralf Mardorf writes:
>>>
>>>
>>>
If something needs to be broken, because of the development,
it shouldn't be released. We won't practise on stage, we practise in
the rehearsal room
Henry Gomersall wrote:
> On Tue, 2009-05-19 at 18:26 +0200, Ralf Mardorf wrote:
>
>> I'm using Linux since years (not rt-audio ;)) and the architecture of
>> Linux has one big disadvantage. You might have a Linux that is fine,
>> the
>> times are changing and in addition you need an absolutely
On Tue, 2009-05-19 at 18:27 +0200, Fons Adriaensen wrote:
> On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham wrote:
>
> > I have to say, I think this is really out of line, Fons. Implying free
> > software developers are theives because they've changed something and
> > you don't like it is quit
Ralf Mardorf writes:
> Nedko Arnaudov wrote:
>> Ralf Mardorf writes:
>>
>>
>>> If something needs to be broken, because of the development,
>>> it shouldn't be released. We won't practise on stage, we practise in
>>> the rehearsal room.
>>>
>>
>> In open source world, with public source
Nedko Arnaudov wrote:
> Ralf Mardorf writes:
>
>
>> If something needs to be broken, because of the development,
>> it shouldn't be released. We won't practise on stage, we practise in
>> the rehearsal room.
>>
>
> In open source world, with public source control repos each commit is a
> p
On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham wrote:
> I have to say, I think this is really out of line, Fons. Implying free
> software developers are theives because they've changed something and
> you don't like it is quite extraordinary.
I did not imply such a thing. You are completely
Ralf Mardorf wrote:
> Sometimes a coder or a packer (packages builder?!) don't work as
> intensive with 'hi' application as the community does, so he can fail
> to see some issues.
'hi' is missing an 's', it should be 'his' ... I guess my English is too
broken, so there seems to be the need to c
Ralf Mardorf writes:
> If something needs to be broken, because of the development,
> it shouldn't be released. We won't practise on stage, we practise in
> the rehearsal room.
In open source world, with public source control repos each commit is a
publish. So you got a camera in your rehearshal
Bob Ham writes:
> On Tue, 2009-05-19 at 10:37 +0200, Fons Adriaensen wrote:
>
>> Someone sets up a firm that provides a free service:
>> they enhance your life by removing things from your
>> home and disposing of them.
>>
>> One day I return home and find some things have been
>> removed.
>>
>
Bob Ham wrote:
> On Tue, 2009-05-19 at 10:37 +0200, Fons Adriaensen wrote:
>
>
>> Someone sets up a firm that provides a free service:
>> they enhance your life by removing things from your
>> home and disposing of them.
>>
>> One day I return home and find some things have been
>> removed.
>>
>
On Tue, 2009-05-19 at 10:37 +0200, Fons Adriaensen wrote:
> Someone sets up a firm that provides a free service:
> they enhance your life by removing things from your
> home and disposing of them.
>
> One day I return home and find some things have been
> removed.
>
> I go the manager of the fre
torb...@gmx.de writes:
> On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko Arnaudov wrote:
>> > however, by having jackdbus in the picture and when everybody would think
>> > it would be the holy grail, it is breaking all that instead just because
>> > it wants to rule the game on its own. it's doin
On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko Arnaudov wrote:
> "Rui Nuno Capela" writes:
>
> >> So you complain about qjackctl missing support for jackdbus? Having that
> >> will be nice :)
> >>
> >
> > from where i stand, qjackctl does not need jackdbus support whatsoever.
> > it's kind of th
torb...@gmx.de writes:
> so please tell me why the dbus implementation CANT just read .jackdrc ?
> i am really pissed on all you guys trampling on legacy stuff.
It can. Nobody has implemented it.
> WHY cant jackdbus just use the .jackdrc if it does not find its own .xml
> config ? or check, whet
Patrick Shirkey writes:
> Nedko Arnaudov wrote:
>> Stéphane Letz writes:
>>
>>
>>> First we have to get a consensus on this "runtime choice of auto-start
>>> strategy", then we'll have to find the best way to implement it.
>>>
>>
>> I was against mixed jack1/jack2 and i'm against the run
On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis wrote:
> On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela wrote:
> >
> > from where i stand, qjackctl does not need jackdbus support whatsoever.
> > it's kind of the other way around, if i may say. and the way around is not
> > about qjackctl p
Nedko Arnaudov wrote:
> Stéphane Letz writes:
>
>
>> First we have to get a consensus on this "runtime choice of auto-start
>> strategy", then we'll have to find the best way to implement it.
>>
>
> I was against mixed jack1/jack2 and i'm against the runtime choice
> now. IMHO it complic
Stéphane Letz writes:
> First we have to get a consensus on this "runtime choice of auto-start
> strategy", then we'll have to find the best way to implement it.
I was against mixed jack1/jack2 and i'm against the runtime choice
now. IMHO it complicates things for user instead of simplifying it.
Le 19 mai 09 à 11:29, Sampo Savolainen a écrit :
> Quoting "Fons Adriaensen" :
>
>> I would have no objection if you added e.g.
>>
>> jack_client_open_via_dbus()
>
> How is the application supposed to know whether the user wants to use
> dbus or not?
>
>> leaving the original call as it is.
>
>
Quoting "Fons Adriaensen" :
> I would have no objection if you added e.g.
>
>jack_client_open_via_dbus()
How is the application supposed to know whether the user wants to use
dbus or not?
> leaving the original call as it is.
I agree with Stephanes' 5):
An implementation where dbus and "
Fons Adriaensen writes:
> On Tue, May 19, 2009 at 11:23:07AM +0300, Nedko Arnaudov wrote:
>
>> It is not intercepted. It is implemented. No hooking is made.
>> jack_client_open() action is not modified. It behaves as expected, as
>> documented in the API. jack server is autostarted.
>
> It's not
On Tue, May 19, 2009 at 11:23:07AM +0300, Nedko Arnaudov wrote:
> It is not intercepted. It is implemented. No hooking is made.
> jack_client_open() action is not modified. It behaves as expected, as
> documented in the API. jack server is autostarted.
It's not just a different implementation. It
Fons Adriaensen writes:
> On Tue, May 19, 2009 at 10:03:28AM +0300, Nedko Arnaudov wrote:
>
>> Fons Adriaensen writes:
>>
>> > Well, the current implementation *does* intercept C API
>> > calls in order to divert them to dbus, it's not just an
>> > addition to the standard jackd. I never mentio
On Tue, May 19, 2009 at 10:03:28AM +0300, Nedko Arnaudov wrote:
> Fons Adriaensen writes:
>
> > Well, the current implementation *does* intercept C API
> > calls in order to divert them to dbus, it's not just an
> > addition to the standard jackd. I never mentioned babies
> > being eaten.
>
> A
Fons Adriaensen writes:
> On Mon, May 18, 2009 at 10:50:01PM +0100, Krzysztof Foltman wrote:
>
>> I don't see the problem, let alone OMG INTERCEPTING C API CALLS!!11! or
>> eating babies.
>
> Well, the current implementation *does* intercept C API
> calls in order to divert them to dbus, it's no
On Mon, May 18, 2009 at 10:50:01PM +0100, Krzysztof Foltman wrote:
> I don't see the problem, let alone OMG INTERCEPTING C API CALLS!!11! or
> eating babies.
Well, the current implementation *does* intercept C API
calls in order to divert them to dbus, it's not just an
addition to the standard j
Fons Adriaensen wrote:
> There is IMHO *no* reason why jack-dbus should
> **intercept** C API calls, start its daemon,
> and take control.
Hmm?
libjack from non-DBUS package detects if JACK server is running, if not,
it starts the server by doing fork&exec.
libjack from DBUS package detects if J
On Monday 18 May 2009 12:50:50 Paul Davis wrote:
> On Mon, May 18, 2009 at 12:34 PM, Fons Adriaensen
wrote:
> > Jack-dbus is not just an (optional) server using
> > the C API and providing access to it via dbus.
> >
> > I don not know what exactly is happening but it
> > interferes even if client
On Monday 18 May 2009 12:34:41 Fons Adriaensen wrote:
> On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis wrote:
> > the issue that qjackctl could consider is not jackdbus, or dbus in
> > general. its the JACK control API that was discussed at LAC 2008.
> > right now, qjackctl simply claims to k
On Monday 18 May 2009 17:57:39 Nedko Arnaudov wrote:
> Fons Adriaensen writes:
> > 1. Dbus is just a communication layer.
> > 2. Dbus adds functionality that can't be
> >provided via the normal interfaces.
> > Both can't be true at the same time.
> they are both false but even if they were tru
On Mon, May 18, 2009 at 12:34 PM, Fons Adriaensen wrote:
>
> Jack-dbus is not just an (optional) server using
> the C API and providing access to it via dbus.
>
> I don not know what exactly is happening but it
> interferes even if clients are just using the
> C API. And it breaks it.
as far as w
On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis wrote:
> the issue that qjackctl could consider is not jackdbus, or dbus in
> general. its the JACK control API that was discussed at LAC 2008.
> right now, qjackctl simply claims to know how to start the JACK
> server, offers a dialog to let th
Paul Davis writes:
> On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela wrote:
>>
>> from where i stand, qjackctl does not need jackdbus support whatsoever.
>> it's kind of the other way around, if i may say. and the way around is not
>> about qjackctl per se, but to plain old good command-line j
"Rui Nuno Capela" writes:
>> So you complain about qjackctl missing support for jackdbus? Having that
>> will be nice :)
>>
>
> from where i stand, qjackctl does not need jackdbus support whatsoever.
> it's kind of the other way around, if i may say. and the way around is not
> about qjackctl per
On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela wrote:
>
> from where i stand, qjackctl does not need jackdbus support whatsoever.
> it's kind of the other way around, if i may say. and the way around is not
> about qjackctl per se, but to plain old good command-line jackd.
i'd like to clarify
Fons Adriaensen writes:
> On Mon, May 18, 2009 at 06:08:33PM +0300, Nedko Arnaudov wrote:
>
>> You have installed jack package that does not work well with
>> qjackctl (dbus enabled one). Your application autostarted jack server
>> through dbus.
>
> It did not. No jack app here uses dbus.
If i g
On Mon, May 18, 2009 16:08, Nedko Arnaudov wrote:
> Fons Adriaensen writes:
>
>> On Mon, May 18, 2009 at 05:13:19PM +0300, Nedko Arnaudov wrote:
>>
>>
>>> Fons I think we can both read C code, right?
>>>
>>>
>>> From posix/JackPosixServerLaunch.cpp, line 166:
>>>
>>>
>>> static int start_server(co
On Mon, May 18, 2009 at 06:08:33PM +0300, Nedko Arnaudov wrote:
> You have installed jack package that does not work well with
> qjackctl (dbus enabled one). Your application autostarted jack server
> through dbus.
It did not. No jack app here uses dbus.
> jackdrc style commandline options for j
Fons Adriaensen writes:
> On Mon, May 18, 2009 at 05:13:19PM +0300, Nedko Arnaudov wrote:
>
>> Fons I think we can both read C code, right?
>>
>> From posix/JackPosixServerLaunch.cpp, line 166:
>>
>> static int start_server(const char* server_name, jack_options_t options)
>> {
>> if ((optio
On Mon, May 18, 2009 at 05:13:19PM +0300, Nedko Arnaudov wrote:
> Fons I think we can both read C code, right?
>
> From posix/JackPosixServerLaunch.cpp, line 166:
>
> static int start_server(const char* server_name, jack_options_t options)
> {
> if ((options & JackNoStartServer) || getenv("J
Fons Adriaensen writes:
> On Mon, May 18, 2009 at 03:14:08PM +0300, Nedko Arnaudov wrote:
>
>> The configuration file is stored in
>> ~/.config/jack/conf.xml
>> (location conforming to the XDG Base Directory Specification).
>
> Frankly I don't give a damn for that spec, or in fact
> anything from
On Mon, May 18, 2009 10:15, Nedko Arnaudov wrote:
> "Rui Nuno Capela" writes:
>
>> On Mon, May 18, 2009 09:17, Nedko Arnaudov wrote:
>>
>>>
>>> Using the "dbus ate my babies" matra is causing mess because other
>>> people don't think so. Using dbus interface in qjackctl would fix lot
>>> of this m
Fons Adriaensen writes:
> On Mon, May 18, 2009 at 12:15:10PM +0300, Nedko Arnaudov wrote:
>
>> libjack does not start jack server if JackNoStartServer is
>> specified. This behaviour is same for both jackd autolaunching and dbus
>> jack server starting through activation. Presense of the jackdbus
On Mon, May 18, 2009 at 03:14:08PM +0300, Nedko Arnaudov wrote:
> The configuration file is stored in
> ~/.config/jack/conf.xml
> (location conforming to the XDG Base Directory Specification).
Frankly I don't give a damn for that spec, or in fact
anything from that self-styled group of *** wh
On Mon, May 18, 2009 at 12:15:10PM +0300, Nedko Arnaudov wrote:
> libjack does not start jack server if JackNoStartServer is
> specified. This behaviour is same for both jackd autolaunching and dbus
> jack server starting through activation. Presense of the jackdbus
> process *DOES NOT MEAN* that
drew Roberts writes:
> How does dbus know what parameters to start jack with? Where is that
> configured? (Perhaps this will solve the issue, I don't recall this
> information passing before my eyes in this thread so far.)
jackbus reads the configuration file and then start jack server through
On Monday 18 May 2009 05:49:01 Jan Weil wrote:
> If it is indeed a
> compile time option, the design is flawed IMHO. Generally, the new
> control API sounds like a good idea but why can't the new features be
> exposed as new command line tools without dbus dependency per default?
> So you want the
Jan Weil writes:
> On Mon, May 18, 2009 at 01:23:20PM +0400, alex stone wrote:
>> Will we continue to have a Jack version minus the dbus infrastructure,
>> once jack2 is released?
>
> As an uninvolved observer I am wondering why the dbus control interface,
> if it is indeed only one of many poten
alex stone writes:
> So again, i'll ask the question.
>
> Will we continue to have a Jack version minus the dbus infrastructure,
> once jack2 is released?
>
> Or are we destined to be dragged into a "compulsory" hybrid?
>
> I share Fon's concerns, and still don't understand why the dbus/pulse
> m
On Mon, May 18, 2009 at 01:23:20PM +0400, alex stone wrote:
> Will we continue to have a Jack version minus the dbus infrastructure,
> once jack2 is released?
As an uninvolved observer I am wondering why the dbus control interface,
if it is indeed only one of many potential interfaces using the c/
So again, i'll ask the question.
Will we continue to have a Jack version minus the dbus infrastructure,
once jack2 is released?
Or are we destined to be dragged into a "compulsory" hybrid?
I share Fon's concerns, and still don't understand why the dbus/pulse
momentum is taking precedence over wh
"Rui Nuno Capela" writes:
> hi Nedko,
>
> On Mon, May 18, 2009 09:17, Nedko Arnaudov wrote:
>>
>> Using the "dbus ate my babies" matra is causing mess because other
>> people don't think so. Using dbus interface in qjackctl would fix lot of
>> this mess and this is the reason I asked Rui about th
hi Nedko,
On Mon, May 18, 2009 09:17, Nedko Arnaudov wrote:
>
> Using the "dbus ate my babies" matra is causing mess because other
> people don't think so. Using dbus interface in qjackctl would fix lot of
> this mess and this is the reason I asked Rui about that. Of course "dbus
> ate my babies"
Paul Davis writes:
> On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz wrote:
>> After all these discussions on JACK2, D-Bus and Qjackctl issues, here are
>> some general comments:
>>
>> 1) JACK2 *default* compilation mode defines the same starting scheme at
>> JACK1 was doing. So (beside possible
Fons Adriaensen writes:
> On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote:
>
>> I really appreciate your feedback..., but AFAICS Qjackctl is *absolutely*
>> not using the DBUS layer!
>
> Then please tell what this is: (ps -ef output)
>
> fons 2444 1 0 10:43 ?00:
"MarcO'Chapeau" writes:
> On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen
> wrote:
>> The only argument pro using dbus I'v heard so far
>> is that it permits run-time discovery of new backends,
>> internal clients and their parameters.
>
> That's unfair. Read the archives. There are more arg
On Sun, May 17, 2009 at 08:04:54PM +0200, Stéphane Letz wrote:
> The point is that when compiled in D-Bus mode, libjack behaves differently
> regarding the way it start the server: it does not use the fork+exec mode
> anymore but call the D-Bus service to start the server. This "simple"
> chang
On Sun, 17 May 2009 13:57:29 -0400, Paul Davis
wrote:
> On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz wrote:
>> After all these discussions on JACK2, D-Bus and Qjackctl issues, here
are
>> some general comments:
>>
>> 1) JACK2 *default* compilation mode defines the same starting scheme at
>> JAC
hollun...@gmx.at wrote:
> I noticed some of the issues with qjackctl and am glad they got
> addressed now.
>
> One question is still open tough:
> Where does jack get it's options when it's auto-started by an
> application (not ardour, that's not an auto-start imho).
>
that's exactly the purpose
On Sunday 17 May 2009 14:04:54 Stéphane Letz wrote:
> The point is that when compiled in D-Bus mode, libjack behaves
> differently regarding the way it start the server: it does not use
> the fork+exec mode anymore but call the D-Bus service to start the
> server. This "simple" change is the
I noticed some of the issues with qjackctl and am glad they got
addressed now.
One question is still open tough:
Where does jack get it's options when it's auto-started by an
application (not ardour, that's not an auto-start imho).
Regards,
Philipp
___
On Sun, 17 May 2009 12:14:26 -0400
drew Roberts wrote:
> On Sunday 17 May 2009 07:31:03 Fons Adriaensen wrote:
> > 1. I definitely want to be able to terminate qjackctl
> > without stopping jackd, even if that jackd was started
> > by qjackctl. This used to be possible.
>
> Indeed it did. I used
Le 17 mai 09 à 20:10, Paul Davis a écrit :
> On Sun, May 17, 2009 at 2:04 PM, Stéphane Letz wrote:
>>
>> The point is that when compiled in D-Bus mode, libjack behaves
>> differently
>> regarding the way it start the server: it does not use the fork
>> +exec mode
>> anymore but call the D-Bus
On Sun, May 17, 2009 at 2:04 PM, Stéphane Letz wrote:
>
> The point is that when compiled in D-Bus mode, libjack behaves differently
> regarding the way it start the server: it does not use the fork+exec mode
> anymore but call the D-Bus service to start the server. This "simple" change
> is the s
Le 17 mai 09 à 19:57, Paul Davis a écrit :
> On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz wrote:
>> After all these discussions on JACK2, D-Bus and Qjackctl issues,
>> here are
>> some general comments:
>>
>> 1) JACK2 *default* compilation mode defines the same starting
>> scheme at
>> JAC
On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz wrote:
> After all these discussions on JACK2, D-Bus and Qjackctl issues, here are
> some general comments:
>
> 1) JACK2 *default* compilation mode defines the same starting scheme at
> JACK1 was doing. So (beside possible bugs) it is supposed to be c
On Sun, May 17, 2009 at 05:04:28PM +0100, Rui Nuno Capela wrote:
> simply because QProcess::startDetached() sets the process loose of
> qjackctl control and all the IPC and inter-process sync facilities and
> notification signal/slots will be useless or no-ops in that way--you'd
> better start jac
On Sun, May 17, 2009 11:43 am, Gabriel M. Beddingfield wrote:
>
> On Sun, 17 May 2009, Rui Nuno Capela wrote:
>
>>> Why not use QProcess::startDetached() ?
>>
>> simply because QProcess::startDetached() sets the process loose of
>> qjackctl control and all the IPC and inter-process sync facilities
On Sun, 17 May 2009, Rui Nuno Capela wrote:
>> Why not use QProcess::startDetached() ?
>
> simply because QProcess::startDetached() sets the process loose of
> qjackctl control and all the IPC and inter-process sync facilities and
> notification signal/slots will be useless or no-ops in that way-
Gabriel M. Beddingfield wrote:
> On Sun, May 17, 2009 8:07 am, Rui Nuno Capela wrote:
>> unfortunately, Qt4's class which is being used for wrapping the jackd
>> process (QProcess) does kill it on its destructor. afaict, this behavior
>> wasn't present in Qt3 and that's why there's no option to kee
On Sunday 17 May 2009 07:31:03 Fons Adriaensen wrote:
> 1. I definitely want to be able to terminate qjackctl
> without stopping jackd, even if that jackd was started
> by qjackctl. This used to be possible.
Indeed it did. I used to do it all the time. I have noticed I had problems
with this rece
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
drew Roberts schrieb:
> On Sunday 17 May 2009 05:24:04 Christian wrote:
>> Fons Adriaensen schrieb:
>>> On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote:
On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen
wrote:
>
On Sunday 17 May 2009 05:24:04 Christian wrote:
> Fons Adriaensen schrieb:
> > On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote:
> >> On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen
> >>
> >>
> >> wrote:
> >>> A request to the jackdmp and qjackctl devs:
> >>>
> >>>PLEASE REMOV
On Sun, May 17, 2009 at 02:07:55PM +0100, Rui Nuno Capela wrote:
> unfortunately, Qt4's class which is being used for wrapping the jackd
> process (QProcess) does kill it on its destructor. afaict, this behavior
> wasn't present in Qt3 and that's why there's no option to keep jackd
> running upon
On Sun, May 17, 2009 8:07 am, Rui Nuno Capela wrote:
> unfortunately, Qt4's class which is being used for wrapping the jackd
> process (QProcess) does kill it on its destructor. afaict, this behavior
> wasn't present in Qt3 and that's why there's no option to keep jackd
> running upon quitting qja
Fons Adriaensen wrote:
> On Sun, May 17, 2009 at 11:48:57AM +0100, Rui Nuno Capela wrote:
>
>> qjackctl only writes to ~/.jackdrc *iif* you opt to (see Setup/Misc/Save
>> JACK audio server configuration). otherwise it *never* makes use of that
>> file ie. it never auto-starts jackd implicitly; it
On Sun, 2009-05-17 at 14:17 +0200, Fons Adriaensen wrote:
> Anyway, you don't need dbus, just provide a start()
> function in the control interface, accepting the
> options in a string, or as an argv[]. Why doesn't
> this exist ? Why do you have to go through all the
> movements of scanning paramet
On Sun, May 17, 2009 at 01:43:55PM +0200, MarcO'Chapeau wrote:
> The code for the legacy behavior might make jack a few lines lighter, but
> have you looked at qjackctl's code ? Starting jack via some pseudo command
> line scripting using Qt and c++ is not something I'd like to maintain.
Starting
On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen
wrote:
> The only argument pro using dbus I'v heard so far
> is that it permits run-time discovery of new backends,
> internal clients and their parameters.
That's unfair. Read the archives. There are more arguments to that.
> Dbus assumes ther
On Sun, May 17, 2009 at 11:48:57AM +0100, Rui Nuno Capela wrote:
> qjackctl only writes to ~/.jackdrc *iif* you opt to (see Setup/Misc/Save
> JACK audio server configuration). otherwise it *never* makes use of that
> file ie. it never auto-starts jackd implicitly; it only does start jackd
> explic
On Sun, May 17, 2009 at 12:20:34PM +0200, MarcO'Chapeau wrote:
> - dbus is not the default compile time config option. Your distro should
> probably disable it (until it's stable and shiny)
On this I agree.
> - When dbus is active, it is indeed not backwards compatible with the
> legacy autostar
Stéphane Letz wrote:
>> To whom it may concern: (again)
>>
>> Jackdmp 1.9.2, Qjackctl 0.3.4
>>
>> I do the following:
>>
>> - Log in.
>> - Start a jack app.
>> - The app starts jackd, but using the wrong card,
>> and things don't work as expected.
>>
>> Questions:
>>
>> 1. Which parameters are u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fons Adriaensen schrieb:
> On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote:
>
>> On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen
>> wrote:
>>> A request to the jackdmp and qjackctl devs:
>>>
>>>PLEASE REMOVE THAT DBUS MADNESS
>
On Sun, 17 May 2009 11:23:03 +0200, Fons Adriaensen
wrote:
> On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote:
>
>> On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen
>>
>> wrote:
>> > A request to the jackdmp and qjackctl devs:
>> >
>> >PLEASE REMOVE THAT DBUS MADNESS
>>
>>
On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote:
> On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen
> wrote:
> > A request to the jackdmp and qjackctl devs:
> >
> >PLEASE REMOVE THAT DBUS MADNESS
>
> Hi Fons,
>
> As long as there's a compile time switch, I don't see how d
Le 17 mai 09 à 10:57, Fons Adriaensen a écrit :
> On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote:
>
>> I really appreciate your feedback..., but AFAICS Qjackctl is
>> *absolutely*
>> not using the DBUS layer!
>
> Then please tell what this is: (ps -ef output)
>
> fons 2444
On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote:
> I really appreciate your feedback..., but AFAICS Qjackctl is *absolutely*
> not using the DBUS layer!
Then please tell what this is: (ps -ef output)
fons 2444 1 0 10:43 ?00:00:00 /usr/bin/jackdbus auto
Killing
On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen
wrote:
> A request to the jackdmp and qjackctl devs:
>
>PLEASE REMOVE THAT DBUS MADNESS
Hi Fons,
As long as there's a compile time switch, I don't see how dbus could ever
be a problem for those who don't want to use it... and for those wh
> To whom it may concern: (again)
>
> Jackdmp 1.9.2, Qjackctl 0.3.4
>
> I do the following:
>
> - Log in.
> - Start a jack app.
> - The app starts jackd, but using the wrong card,
> and things don't work as expected.
>
> Questions:
>
> 1. Which parameters are used for such an autostart ?
> C
100 matches
Mail list logo
