You are here

Aux Send usage clarification

Hi Rui,

I've just returned to Qtractor after a work-enforced absence and am having problems with the Aux Send feature. Could you clarify the intended purpose of this feature please? Specifically, I'd like to find out the following:

1) As I understand things from your previous comments, Aux Sends are for internal routing and Inserts are for external. Is that correct?

2) When routing a signal from a Track (MIDI or Audio) via an Aux Send to an internal Bus (Duplex), where is the signal supposed to go after this? Does it automatically return to the Track and get routed through the Track's "Output" destination (as chosen in the "Track" dialogue box), or does it stay in the Bus (and therefore should be routed manually, via Connections or something)?

What I'm attempting to do is to send several tracks (either MIDI or Audio) to one Reverb Bus, via Aux Sends in the Tracks, so that they can share the same reverb plugin (with varying levels of gain via the Aux Send's dialogue box), then export this (and other tracks) via the Master Audio export.

I've been using the Mixer to set all this up (as you've told me to do previously) and, from checking there, the signal is registering in the Reverb Bus, but I can't hear any reverb effect. In order to hear it, I have to connect the Reverb Bus' outputs to system 1 & 2 in Connections. Is this what I should be doing?

In addition, when exporting the Master Audio output, the reverb is not present. To be able to export this, I have to export the _Reverb Bus_ output, which isn't much use to me as I'd like to (if possbible) have several shared Buses, all eventually ending up at the Master Audio out.

In short, I'm not at all sure how the system is supposed to work. I know from your previous comments that it's not an Ardour-style "anything to anywhere" system, but can't seem to work out what it's doing. FYI, the Inserts feature appears to be fine - I can route out to Jamin and back into Qtractor, then export, with no problem. It's just the internal routing that I'm stumped on.

Any help would be very much appreciated. I'm running from SVN.

rncbc's picture

re. 1) As I understand things from your previous comments, Aux Sends are for internal routing and Inserts are for external. Is that correct?


re. 2) When routing a signal from a Track (MIDI or Audio) via an Aux Send to an internal Bus (Duplex), where is the signal supposed to go after this?

signal goes through the target bus output ports; yes, you'll have to connect them to whatever you do for listening or monitoring, or further processing (via the JACK graph outside of qtractor); yes, you can only export the output of one audio output bus at a time.

in summary, internal routing goes only on the forward direction, never feedback:

input -> input-bus -> tracks -> output-bus -> output

the purpose of aux-sends is to serve you to fork the signal path on its way to output; you can't have aux-sends from an output-bus to another output-bus--this might only work *iif* the originating bus appears *before* the destination bus. as buses are sorted in create order that will only work just by chance, not by design.

have a look back to the following diagrams:)

a. the aux-send plugin block-diagram:
b. the general bus / tracks diagram:

Thanks as ever for the quick, detailed reponse. I've been working with this again today after reading your comments and looking at the diagrams, but I'm still not sure if what I'm trying to do is possible.

My basic questions is - is it possible to have multiple tracks routed through different buses (e.g. strings reverb bus, brass reverb bus, percussion reverb bus etc), then have the output of all these buses end up at the Master Out (or anywhere else "convenient"), so that I can then export everything together (rather than export the individual buses)? If this is not possible using Aux Sends (which I'm using in order to control Send Gain) and Buses, is it possible via some other method?

From your response, I think I may be going about this in the wrong way, but if the above _is_ possible, I'm really not sure how to approach it. Again, any help would be very much appreciated.

rncbc's picture

re. is it possible to have multiple tracks routed through different buses (..) then have the output of all these buses end up at the Master Out (or anywhere else "convenient"), so that I can then export everything together ?
no, it is not possible, yet. audio track export only does its thing via one and only one single audio bus atm.
fwiw. sounds like kind of a new feature request to me :) file a ticket please, before oblivion takes its due :)

Thanks for the info - I've opened a ticket. I wasn't quite sure how you wanted it wording in terms of the actual method of addressing this, so have kept it quite general. I imagine it's a non-trivial thing to implement, but if you do get the time to look at this at any point, I think it'd be a big improvement.

In addition, after playing with the latest version for the last couple of days, I've discovered a small bug and thought of a couple of ideas for the piano roll (or rather, stolen them from Rosegarden :-)). I'll list them here - please let me know whether you're interested in them at all.

When this window has focus, attempting to save with Ctrl-S does not work. If the user clicks on the main editor window to give it focus (leaving the piano roll window open/minimised) and presses Ctrl-S, saving will work and the piano roll window will then automatically appear in front of the main window. At this point, anything selected in the "Parameter Type" menu of the piano roll will reset to default. For example:

1) In piano roll, choose "Controller" in "Value Type" menu and "7 - Volume (coarse)" in "Parameter Type"
2) Make any kind of change in piano roll, to allow save operation
3) Click in the main Editor window to give it focus (leaving the piano roll window open/minimised), then press Ctrl-S to save. The piano roll will then come back into view
4) Note that "7 - Volume (coarse)" in "Parameter Type" has returned to the default, "0 - Bank Select (coarse)"
*I've tried a few "Parameter Type"/"Value Type" menu combinations and this seems to happen every time.

Pressing Ctrl-S while the piano roll has focus should (at least to my mind) save the project; no other options should change.

PIANO ROLL - SELECT ALL (feature idea)
In Rosegarden, holding Shift and selecting a piano key on the left of the piano roll selects all notes of that pitch. This is a very handy feature and I think something similar in Qtractor would be great.

PIANO ROLL - SHORTCUTS (feature idea)
In Rosegarden, pressing Ctrl and up/down arrow with a note/notes highlighted moves them up/down an octave. Again, a handy feature.

rncbc's picture

you never know whether it's trivial or not, unless you know the code inside out.
well, it's done already. svn trunk v0.5.11.16+ awaits your experience ;)

yeah, confirmed. will look at it sooner than later... maybe already fixed on svn trunk of course ;).

re. PIANO ROLL - SELECT ALL (feature idea)
maybe i missed some, but click-n-drag on the (fake) piano keyboard on the left pane doesn't do it for you? and shift/ctrl will also select non-contiguous note lines, jfyi.

re. PIANO ROLL - SHORTCUTS (feature idea)
currently, holding shift/ctrl+arrow-keys will just scroll a slice (shift) or a page(ctrl); not sure whether option is intuitive enough. but i'll try :)


Thank you indeed :-) I've just tested this out on and was able to export multiple buses by selecting them in the Export Audio window. I'll do some more intensive testing to see if anything weird happens (e.g. when sending multiple buses out to JAMin etc) and report back if there are any problems. This new feature is a huge bonus for me personally and I think it should benefit a lot of others too.

OK, will check back on this.

re. PIANO ROLL - SELECT ALL (feature idea)
Ah, I see - click and drag to the right! Didn't know about that. Yes, that's exactly what I was looking for.

re. PIANO ROLL - SHORTCUTS (feature idea)
If you think it's worth putting it, please do; if not, no problem. It's only a minor feature, but I found myself using it a lot in Rosegarden once I discovered it, so thought I'd mention it.

Thanks again for the ridiculously fast work :-)

Hi Rui,

I've finally had time to play with the multiple bus export feature and wanted to get your thoughts on the below observations. I'm now running

If you export multiple buses in which the signal is reasonably hot (though not clipping), when these are exported together, the exported file can easily clip. I first noticed this when using the limiter in JAMin, but after investigating further, I found that you can easily reproduce this without JAMin.

I imagine it's caused by the output of the buses being mixed together, making the overall signal louder? I'm not sure how you want the multiple bus feature to work exactly, but personally, I think it'd be nice if the multiple buses could be "collected" by the Master out bus - then you could just export this one bus. Doing it this way would also enable you to put all the stuff you want at the end of the chain (JAMin, goniometer, performing a mono check, whatever it may be) in one place, rather than duplicating everything in each bus. As I say, I'm not sure of your intentions for the buses, but I'd like to hear your thoughts on this.

Not sure if you've actively addressed this, but FYI, here is the behaviour in this version:

- Ctrl-S with the piano roll window having focus doesn't perform a save (as per original bug)
- Ctrl-S with the main editor having focus does perform a save, bringing the piano roll window back to the foreground (as per original bug). However, the "Parameter Type" menu select will now not return to default (this part is fixed)

There seems to be something fishy going on with Tempo Map/Markers but I haven't been able to track this down yet. In the time I've been using Qtractor, I've seen things not restoring the way they were upon re-opening a file. For example, if I use "Update" to change a previously inserted tempo, this change may not have saved upon re-opening; or after inserting/modifying multiple time signature changes, one or more might be missing upon re-opening. I've only had this happen on decent-sized projects and haven't been able to reproduce with a simple test project.

I know the above is a terrible attempt at a bug report, but do you have any ideas about how I can try to "break" this intentionally and so track down what's happening? I looked for similar issues on this forum and on Sourceforge and thought it might be connected to this bug, but I'm not quite sure:

However, what he says about multiple tempo changes making a mess of the tempo mappings does sound similar to what I've experienced. I also often have multiple tempo/time signature changes (partly caused by working around the lack of tempo ramping) and so have run into this problem.

Anyway, please let me know your thoughts on the above and if you need more info, any tickets opening etc.

rncbc's picture


yes. it's caused by the multiple buses output being mixed (added) straight together. fact is that the whole mix may well exceed the regular audio full-scale for floating-point sample data format, which is [-1.0, +1.0] (0dBfs) and when it does it get's hard-clipped when exporting/converting/writing into a non-float sample file format (eg. standard 16bit signed WAV).

you have two choices: a) dim out the output volume of each bus as much until the whole mix doesn't ever over 0dBfs, ever; you can monitor this with some external meter(ing or ppm), the connections of which replicate the converging multiple buses you're trying to export. b) export to a float sample file format (eg. ogg vorbis) where hard-clipping doesn't occur at the disk file data storage representation and you'll get the chance to control and overcome those clipping artifacts later on in the process chain eg. when ultimately rendering to DAC/soundcard, through simple attenuation (ie. volume/fader/whatever;))


pressing Ctrl+S while the MIDI clip editor is up just saves the MIDI file that you're working on that precise MIDI clip, not the whole qtractor session (or, if you prefer, project or song);

pressing Ctrl+S while the main window has focus is the way to save the whole show.

you might find it wrong, redundant or even confusing, but yay, that's the way it works :) unless, i'm missing the point or something in between :/


this needs more investigation; what exactly is not restoring and when? is it easily reproducible or just happens sometimes and hard to remember what and when?

make sure you get all comments from ticket #63: as repeat ad-nauseum: tempo/time-sig changes must only occur at bar measure positions; there's no way to work around that, i am sorry :) and tempo ramps are not supported either; use the timeshift MIDI tool to emulate accelerando/retardandos on individual MIDI clips, it's not possible to do it any other way, any time soon. sorry.


Thanks as ever for the quick reply. Sorry for the long post yet again, but...

I'm not that familiar with the technicalities of file formats, but after a bit of research, I think I understand :-) I generally export to FLAC for archiving and convert to ogg for distribution, but it seems FLAC doesn't support floating point. So to confirm - if I were to switch to, say 32 bit float WAV and export a file which is clipped, do you mean that I can just lower the level of the sample to 0dB or below and this will preserve all the data? I've just done some tests in Audacity with clipped FLAC and 32 bit float WAV files and they do indeed behave very differently, the WAV file seemingly working OK.

Do you have any thoughts on the second part of the post ("Doing it this way... rather than duplicating everything in each bus")? At the moment, with multiple buses I'm having to connect each one to JAMin etc separately. Is this the intended way? Previously, when using Ardour, I had all the buses etc returning to the Master Out and just added one Insert to JAMin, which was very easy. It seems such an approach might not be possible in Qtractor?

> you might find it wrong, redundant or even confusing, but yay, that's the way it works :)

Yes, I have been utterly confused by this :-) If by pressing Ctrl-S in the MIDI window I am actually saving the work I'm doing in that particular file, then that's fine (as it's the only file I'll be working on at that time). It's still confusing though, as pressing Ctrl-S with the MIDI window having focus doesn't remove the [modified] text from the window. So...

- Should [modified] disappear from the MIDI window upon pressing Ctrl-S (with the MIDI window having focus)?
- If I save "the whole show" in the main editor, open a MIDI window, make a change, then press Ctrl-S (with the MIDI window having focus), should [modified] disappear both from the MIDI window and the main window? Although I'm not saving "the whole show" here, I'm saving the only thing which is having an influence on it

Basically, I think the design as you've explained it is fine, but at the moment, there's no visual feedback as to whether the save has worked or not, which is confusing (at least to me).

> what exactly is not restoring and when?

It's difficult to pin down as I often won't notice that something's gone wrong until much later, but I can give you my recollections/impressions (again, apologies for the vagueness). As I mentioned, if you could give me any hints on the kind of things I can try in order to "break" this, I'd appreciate it.

- I've seen both tempo and time signatures not restore correctly
- Sometimes entries will be present, but incorrect (e.g. tempo figure wrong); sometimes they'll be missing altogether. When things go wrong, it's often the way that not all entries are wrong - some can remain correct
- What seems to happen is that Qtractor can "remember" a previous setting for an entry, then incorrectly revert to this setting after other changes are made later. As time goes on and more changes are made, the problem worsens as Qtractor becomes "more confused"
- I suspect, though really am unsure, that using the "Update" button can throw things off. I've noticed that after making several changes and attempting to "Update", the button will sometimes be greyed out, when it should be active and ready, indicating that at least something isn't right here. Again, it's as if the tempo map is becoming "confused"
- I also suspect (though again am unsure) that making various changes, then returning to make changes in the middle of a list of ones you've already made, can throw things off
- In terms of entries going "missing" - as an example, a piece I was working on had about 6-7 tempo and time signature changes. After working on the file for a while, making saves/re-opening the file, I eventually discovered that only three of these changes remained in the Tempo Map/Markers box. I was unable to work out exactly when things had gone wrong
- The problem seems to happen mostly on re-loading a save, but I think there's a decent chance it's also happening while working on the file in the standard way (see next point)
- I'm reasonably sure I've seen the problem happen in realtime. When playing back MIDI files and following them in the MIDI editor, upon passing over a tempo/time sig mark (not sure which), I'm sure I've seen the window "jump" as the change is re-read (incorrectly?)
- I've tried making changes solely through View -> Tempo Map/Markers and solely by clicking the bar marker area above the MIDI tracks, but neither seems to be stable. Is there any difference in these methods?

> is it easily reproducible or just happens sometimes and hard to remember what and when?

As above, it's difficult to pin down. I've been trying to reproduce in a small test file to be able to send you a .qtz, but haven't been able to get anything so far. I also don't have any examples from previous projects, as due to their having become such a mess, I ended up removing as many of the changes as possible.

> tempo/time-sig changes must only occur at bar measure positions

Yes, I understand. This is no problem.

> use the timeshift MIDI tool to emulate accelerando/retardandos on individual MIDI clips

I did look into this feature previously but it wasn't quite what I needed, as using it throws off the bar lengths (I understand that this is what's it's supposed to be doing). Given that I'll likely still need to adjust the time signatures in order to put in things like brief pauses, and given that tempo changes can only occur in defined places, I think that using both features will make things a bit of a mess. I think I could live without tempo ramping if we could isolate and fix the non-restoring Tempo Map issue.

Just found another small bug during today's tests.

- Right click MIDI clip -> Clip -> Tempo Adjust
- Cancel without making any changes
- "Some settings have been changed." prompt will appear unnecessarily
- n.b. the default settings in the dialogue box will be 90.0 4/4, regardless of the clip's properties. Even when proceeding as above on a clip of 90.0 4/4 (i.e. the same as the default settings), the prompt will still appear unnecessarily

It's very similar to this previous bug:

rncbc's picture

i'm not quite seeing this happening :/ would you care to detail the circumstances?

right-clicking on any clip and Clip/Time Adjust... (F7) then cancelling the dialog immediately doesn't prompt me to anything...


ps. re. tempo map changes issue, i've just bumped into something that might be related to your worries; while exercising undo/redo over and across a loop of couple of clips, incidentally spreading over distinct tempo/time-sig regions, it started to behave a little strange and ended in a mess, like being non-idempotent at all (which is not by original design, i assure you:)) ... fwiw, latest svn trunk, v0.5.11.30...

pps. an then i could not reproduce the bump; still trying though... :/

ppps. and now back to the title subject: i got the Clip/Tempo Adjust dialog to prompt the unnecessary question after all o.O uhoh worms are crawling out of the can :)


Add new comment