You are here

Qtractor 0.4.5 - A Friskier Demivierge is out!

SCNR ;) mostly yet another bug-fix-regression dot release, nuff said.

Qtractor 0.4.5 (friskier demivierge) is out!


  • Changing loop points while playback is rolling, with the play-head any near, was leaving audio clips out-of-sync.
  • MIDI event list view was missing some selected items with the very same onset time, now fixed.
  • When failing to detect a SSE enabled build, the CFLAGS variables are now properly restored to their previous sane state, preventing all subsequent dependency tests from false positives (bug#
  • MIDI clip editor (aka piano-roll) multiple selection has been fixed (again) re. move/paste-snapping consistency.


Project page:


Weblog (upstream support; oh wait...):


Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.

Cheers && Enjoy.


This is looking very cool. Great work.

To install the Ubuntu 9.10 (Karmic) package you need to also install these from the Lucid repository:

rncbc's picture


Didn't know about the librasqal2 in particular needing to be from Lucic repos. I thought it would be a direct and automatic dependency of librdf0 which you also need. However, librdf0 is available from Karmic repos. alright.

Anyway, thanks again.

Or install it from this PPA:



hi there,
it's good to see this software evolves :D.
i compiled last tarball (and svn) to get ladish level 1 support with no success.
when saving studio in gladish, the software keeps on exiting
any idea ? am i supposed to enable (i search configure --help output) ladish lv1 explicitly ?


rncbc's picture

Conforming to LADISH Level 1, an application should save its state in response to SIGUSr1 signal. That's what Qtractor >= 0.4.4 does. Try this:

kill -USR1 `pidof qtractor`

this should do the same as if you would have asked for File/Save from the main menu. Qtractor should NOT exit (provided you're running 0.4.4 or later).


Hejo ... noted that my release builds and svn builds showed different behaviour ... In the main, some odd bug where qtractor would crash trying to read templates (controller, us428) ... and so, I'm building from svn from now on ... will try to add more feedback ... great work!!!

Hejo, as to my last comment ... everything works really well ... 2 (or 4) audio tracks, midi control, live midi for a total or 3 to 5 tracks. control templates no problem, recording works well, control, playback, midi to internally loaded dssi, etc....

however, trying to open a saved session seg faults (same behaviour with last 2 realeases). This is with an svn build. AMD 64 bit debian ...

I could help with debugging (had it off, high hopes :) what's the best forum? This must be a simple bug.... or system dependent condition.


Hejo, ok, did a simple test based on some reading through this site and the source .... from within nautilus (gnome desktop with self-compiled compiz bummff) ... open qtr file in context with qtractor and PRESTO ... file opens properly. HOWEVER, i can't open qtractor at all now if I try to launch it normally (ie. desktop icon, alt-f2 works)

opening a document (recent menu) crash-o-rama ...

It seems to have to do with dbus? Could be that this only effects odd cases. I'm running a lenny with backports that had been a studio 64 box... Hmmm.

In any case, saving works just fine and re-opening in a context works too.


rncbc's picture


First, you can try moving the global configuration file away (~/.config/ It has been reported that starting from scratch is kind of a cure for most of similar faulty behavior.

Second, if the previous suggestion doesn't get you any better, you can try building from source without LV2 support (./configure --disable-lv2). Reasons for this are slight suspicions of a particular bad libslv2 delivery or/and one its dependencies (eg. librdf0). I've been told more than once that magic happens when switching one or all of those dependencies, specially on debian based systems.

Third, if you dare, you should still build from source with debug in mind (./configure --enable-debug). Watch then for stack-trace dumps whenever it segfaults and report back. It also helps if you turn off View/Options.../Display/Capture standard output, so that those segfault stack-traces get caught on the terminal console.


im back after some tests. qtractor DOES respond to SIGUSr1. but when calling save in gladish, it keeps on exiting. i'll have to deal with ladish dev for that. thx

I would like to know more about this cause I don't find it informative.

I just tried Qtractor 0.4.5 on Arch Linux today and I am very impressed with what you have done so far. I've been trying to use various audio/music creation programs on Linux for 10 years and I almost gave up (generally, they have always been unfinished, buggy, slow or absent). Then I tried Qtractor. :-) What a surprise. Clean, easy to use yet powerful, good performance, does not crash... The MIDI features look especially nice. And Qt4 was a smart choice, indeed (the GUI is much faster than in GTK+ based apps like Ardour or BEAST).

Thanks a lot for your work.

rncbc's picture

My turn to say thanks :)

may I ask you to tell about your experience with qtractor in particular? All help is welcome and user manual / documentation writers are godsend ;)



First of all, I really like qtractor - it's an excellent piece of software and easy to use.

However, there's one thing that I don't understand. I'm used to old-skool sequencers that have aux busses (e.g. a track called 'reverb' which has a reverb plug-in set to 100% wet). To apply a reverb to one track, I can simply turn the aux-send knob and this will send some of the track to the reverb strip.
Is this possible in qtractor?

I have read the manual, but I didn't understand the parts about sends and returns.

Many thanks for your hard work!

rncbc's picture

There's no such thing like aux-buses in Qtractor. Not quite.

You can however insert a plugin into an audio track. The amount of plugin effect (wet/dry) is usually a plugin parameter.

Track plugins apply to internal track audio outputs before mix-down into the designated output bus. There's the catch: output buses in Qtractor are mix-down devices, not alternate signal paths. Qtractor buses are indeed the interface devices to the outer world.

In the very same way, you can insert plugins into an output bus. That way, it will apply to the audio output after the mix.

Each track or bus has a plugin chain, meaning that you can chain several plugins one after the other. Only activated plugins apply. Non-active plugins are bypassed. There's also this special kind of inserts which function as taps to either a track or bus. This kind does expose send output ports and return input ports, to and from the outside respectively, which may serve to connect stand-alone JACK enabled applications as regular plugins.


Ah! I see. Thanks for explaining that.

The only missing features (as far as I'm concerned) is being able to draw automation on clips (volume, pan) and an aux/group bus. I really like to use busses and sends (old school stuff, I know)

I've tried lots of other sequencers but qtractor seems the most stable (are you sure it's still alpha? ;) ) so I'll just work around this.

Once again, thanks!

rncbc's picture

Re. Automation is planned for implementation during the current year. There will be one next dot-release just before real work starts, so be patient ;)


I came across a curious (to me, anyway!) anomaly recently when saving a file in Qtractor. I cannot remember the exact sequence but a dialog comes up asking for a file name but does not show the (Nautilus?) window until a filename is entered in your dialog. If one wants to overwrite a previous file, at present one either has to guess or call up a separate file browser to see what name to use.

Sorry, not a very good explanation (and if it doesn't make sense, I'll document a blow-by-blow account of my actions next time ;-) but perhaps your 'save' dialog is superfluous, as the file browser comes up anyway, asking again what and where to save?

Thanks once again for all your excellent work, Senhor.


rncbc's picture

You're probably referring to the first dialog that appears asking for a proper session name and then the second one for the actual file name to be written. This second one is often like the native file requester you get from your desktop environment (Nautilus from Gnome?). The first one is actually necessary for having a proper session name. Session name is not always the same as the file name, though. However that initial session name will be indeed the one suggested for the file name in the second dialog. You see, you only get this behavior when saving brand new sessions, untitled scratch sessions so to speak. That's it.


Add new comment