You are here

aux send

If I understood correctly, when I add an Aux Send to a bus/track, I have to adjust the mixer strip of that channel and the send gain of the Aux to adjust the levels of the clean and "auxed" signal respectively. I'm not sure how this works in other DAWs, but isn't it a bit counter-intuitive? One would expect that the mixer strip adjusts the global volume of that bus, no matter what effects one applies to it, even in Sends - instead as it is now it could be all turned down, but if some part of the signal is going through Aux it will still be heard. Mixing also becomes much more difficult: every time you want to adjust the overall volume of a track that has n Auxs, you have to move n+1 sliders instead of 1.

Wouldn't it be more obvious to have two sliders in the Aux Send window, one for send gain and one for dry/wet proportion, exactly like in the Insert one?

Also, another concern of the current architecture of Auxs. If I get it right, putting two Auxs in a row, your signal will go through these in parallel, not in series.. So you couldn't have a distortion bus, a delay bus, and then add two Auxs to a track to have a distorted delay.

All in all as I see it - couldn't the Aux Send be a perfect replication of the Insert pseudo-plugin, with the only added benefit of having a drop down menu to choose the bus, without having to manually define sends and returns (i.e. sends would automatically be connected to the Ins of the selected Bus, and returns connected to the Outs) ?


nervemind the parallel/series Aux rant... I got it why it makes no sense to put them in series (on the output of an effect bus you'll have *all* the of its inputs passed through the effect)

rncbc's picture

the new "aux-send" pseudo plugin is in fact a derivative of the "insert" pseudo-plugin. big difference is that the "aux-send" one doesn't deal with external ports (jack ports) as the "insert"one does.

the new "aux-send" p-plugin, which you only find in current svn-trunk attotw, is a astonishing work that must be credited to Holger Dehnhardt, although i've been involved only in adapting the code to (my) style only :) thanks to Holger, ntl.

besides that, the "aux-send" p-plugin function is just about a fork of the audio signal from current insert point (be that a track or a bus) and mix (send) into an alternate pre-selected audio output bus (the so-called aux bus one). all this processing is always taken in pre-fader fashion, both the fork point and the mix point. so i guess that a dry/wet is not really necessary in this scenario, nor event relevant.

but i can always miss a point ;)


thanks, the diagram makes it very clear. I think my whole first post can be boiled down to this: is there any reason why to fork the signal pre-fader? Forking it post-fader would maintain the usefulness of the mixer strip fader, whereas in the pre-fader case you would get the difficulties in mixing I was describing in first post (i.e. the mixer fader isn't anymore sufficient to adjust the global volume of a track/bus)

rncbc's picture

re. why to fork the signal pre-fader?
the aux-send p-plugin is a plugin (!), and all plugins are procesed in pre-fader order (visually, as a mnemonic, this order can be read vertically-wise as naturally as from top to bottom, if you look at the mixer strip).


Hi Nareto,
I was discussing the pre/post Fader with Rui when I made the first implementation of the AUX send. There are use-cases for both routing schemes. When using effects - eg. a master reverb to simulate the concert hall, it is easier to do this post fading. If you need a second, third.. mix for monitoring purposes - and you know, there are a lot of difference between the monitor prefences of a guitar player and singer e.g. - a post fader send would make no sense at all.
As Rui described in his answer, having an effect before the fader and using it after the fader is some kind of absurd - on the one hand - on the other hand it has been implemented that way on any hardware mixer I ever had seen...
But I'm convinced - It would be great if we had another effect section behind the fader - or as a consequence - if the fader would be a 'volume plugin' in a row of plugins and you can decide where to put which. (Could be a funny mixer design...)
Let's see what time will bring..


I think this is a really great idea! To insert the fader wherever you want it (by default maybe it could be where it is now if you haven't inserted the "fader psuedo-plugin" at all)

rncbc's picture

i'm sure there's at least one of many LADSPA plugins that can certainly function as a fader pseudo-plugin, same for EQ. plugins you're welcome to try.


Yeah, I mean that's what you have to do now. You use a direct access knob to control the send gain or set the gain on some plugin.

But it's nice to be able to see the volume on the meter, and to have the more fine control that the fader brings, so I really like Holger's idea.

The other thing that's funny about this whole situation is that with MIDI tracks, the situation seems to be reversed. You have no choice BUT to send stuff post-fader. It'd be nice if there was some simple control over where the fader is applied with respect to sends.

I guess for now I'll have to bounce all my tracks to Ardour and mess with them there :/

rncbc's picture

the MIDI tracks faders situation *is* entirely different from audio tracks faders.

MIDI track faders do *not* affect any audio signal stream, at least directly whatsoever, so no matter on here if it's pre or post-fader. It might seem post-fader, just because their control effect is nothing but a causal effect.

MIDI track faders are in fact MIDI channel volume/panning dedicated controllers as they actually send MIDI CC#7 and CC#10, respectively, out to the designated MIDI output bus *and* through the tracks MIDI instrument plugin chain. The latter fact might seem that it's post-fader or as you say reversed when compared to the audio track types. But again, it's not an audio signal we're transmitting there, it's MIDI channel control data that is being conveyed and may cause a possible reaction, thus a post-like effect, on some MIDI instrument, not necessarily affecting that precise plugin's audio output volume (cc#7) nor panning (cc#10) which are conventional (standard GM) and implementations may vary;)


By the way, Qtractor is wonderful. I am only suggesting these things because I use it a lot and plan to continue! Maybe some day I'll get in the code and hack some stuff up myself.


Add new comment