You are here


Thanks for making XG editing available on Linux! I've built a package for OpenPandora as mentioned in other thread (Repo link: It runs nicely even on a small 800x480 px display. It connects with no issues to Yamaha QY100 and makes editing not just easier but also unveils parameters which are not accessible from the device UI, nice!
The only small issue I encountered is that knobs which allow sub-zero values are getting stuck on position 0 although the real values can be still set below zero either by continuing the knob rotation or entering numbers.
Really good work for alpha! Thanks again!

rncbc's picture

thanks for trying qxgedit on openpandora... (ot. speaking of which where's mine i've ordered years ago? :/)

re. stuck knobs: can you just give me a case where this happens? i'm too lazy to check each one of the many knobs in there ;)

[UPDATE: fixed on svn trunk rev.177 aka. qxgedit]


There is a problem I have seen with jack in general that may be somewhat solvable in qjackctl. Qjackctl runs in one of two modes, either with jackd or jackdbus. When in jackdbus mode, qjackctl looks to see if jackdbus is already running and connects through dbus. However, there is some software that if jack is not running starts jackd. Qjackctl does not detect this and then when it tries to start jackdbus this fails, but often the user doesn't know why. Would it be possible to have qjackctl look for jackd running when trying to start jackdbus and put up a dialog asking if qjackctl should first stop the running instance of jackd or run in jackd mode till next jack server shutdown? (or try to start jackdbus anyway if the running jack server is not named "default") I think this would give better user feedback.

Maybe I am missing something too :)

rncbc's picture

yes you're right. qjackctl does function in either of two modes depending whether the jack-server is already running at the time it gets started:

  • if the jack-server is not yet running: qjackctl enters in "Stopped" state; pressing the "Start" button will start the jack-server under its control which leads to the "Started" normal state; pressing "Stop" button will actually terminate the previously started jack-server and will return to the initial "Stopped" state.
  • if the jack-server is already up and running: qjackctl enters the "Active" state and will function as a normal client only; pressing the "Stop" button just deactivates the client functions and will get to the "Inactive" state; it does NOT try to stop the current jack-server whatsoever; pressing the "Start" button gets you back to initial "Active" state and so on.

now, take special attention to this: the jack-server is in fact indirectly started by either jackdbus (the d-bus service controller or whatever it's called) or jackd (the original command-line program and process).

  • if qjackctl is configured to enable the d-bus interface then, pressing the "Start" button from a "Stopped" state will start the jack-server via the jackdbus service which might be auto-started on first time you invoke it--the important thing to note here is that jackdbus process IS NOT the same as the jack-server process; one commands the other, not the other way around.
  • if qjackctl is configured otherwise (ie. d-bus interface disabled) then the regular jackd command-line interface is in charge of starting the jack-server process as always been, ever since its inception 10 years ago :).

the fact that jackd gets automatically started by various applications is a classic feature controlled by the contents of ~/.jackdrc file in your home directory. there you'll find the exact command-line that is run when a jack-enabled application is launched and the jack-server is not up and running at the time.


Thankyou for your very clear answer. Also, much egg on face as I have just been playing with a newer version of qjackctl and the operation is already much clearer than it has been. When qjackctl is started it does detect an already running jack no matter what mode each is in. It is confusing that in the case of another program starting jack and qjackctl stopping it, jack does not in fact stop (ok) however, qjackctl then tells me jack has stopped, when in fact it is still running. Does qjackctl confirm that jack did shut down? Maybe this is what I was seeing. Certainly in the case of dbus operation, dbus returns a stopped status that is true for jackdbus, but not for jackd, but I am not sure how one would check if jack was running. (and I'll probably find that this too is fixed in a version I don't yet have ;) (running 0.3.10 here) Anyway, these are minor things. Perhaps in a one jack world a command line started jack would show up on dbus too... or maybe that would cause even more problems. Thankyou for the jack control program we all use.

rncbc's picture

the lines that follow is my personal setup and must not be considered an official one from whatsoever.

iow. this is not suitable for general distros packaging or recommendation but to the brave and personal setups instead ;)

  1. while on qjackctl, make sure Setup/Misc/"Save JACK audio server configuration to:" option is off; OK and Quit.
  2. then redirect the so called "JACK audio server configuration" file (~/.jackdrc) to run qjackctl, permanently: from the command-line terminal/console (as your regular persona aka. user):

    echo "`which qjackctl` --start" > ~/.jackdrc
    chmod a-w ~/.jackdrc

nb. you need to do the above only once; from that moment on, qjackctl will cold-start itself and the jack-server automagically whenever any jack-client is invoked.

ps. the last chmod step is optional but barely needed to avoid something else to mess with the ~/.jackdrc file--one notable example is ardour, no other, which will present you a jack configuration dialog whenever the jack-server is not running when it starts and then try to override that configuration file without further questions asked :)


yPhil's picture

> qjackctl will cold-start itself and the jack-server automagically whenever any jack-client is invoked

By "jack client" you mean qtractor right ? Because I did try this, and nothing changed. Qtractor, when launched w/o qjackctl, seems to spawn /usr/bin/jackdbus, witch means nothing but unstability and xruns for me.

rncbc's picture

you should check whether the qjackctl d-bus interface is turned on; the above hack does NOT work when jackdbus is in charge--it has its own jack server auto-start configuration as it is NOT the ~/.jackdrc file whatsoever.

if you rely on jackdbus to get your jackd environment up and going then my qjackctl hack does NOT apply at all.


It’s great to hear that XG editing available on Linux. I am using Linux as a secondary booting option and I will try this for sure. I will get back to you shortly with my review on this. Thanks for sharing.

Add new comment