Main menu
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
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)
Re: aux send
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 ;)
hth.
cheers
thanks, the diagram makes it
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)
Re: aux send
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).
byee
Pre/Post Fader
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..
Holger
fader pseudo-plugin
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)
Re: fader pseudo-plugin
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.
cheers
Yeah, I mean that's what you
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 :/
re. MIDI tracks situation
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;)
hth.
cheers
By the way, Qtractor is
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.
Ah! I have been searching for
Ah! I have been searching for this discussion for a while! Now I am convinced that it is not possible currently to do what I'm trying to do.
I asked about the pre/post fader question in this thread. The reason why a "post fader" (and maybe even post pan, mute, etc.) option would be useful to me is that I have some songs where the vocalists do crazy amounts of backing tracks, harmonies, ad libs, etc. It's really a pain to have to EQ all of these individually and if I use the insert or aux send, it's extremely clumsy to adjust the levels using the individual gains!
Is there another way?
nomenclature
Many seem to stumble over the Send-Bus functionality, myself included – I guess it's just a question of nomenclature...
Should Qtractor's “Send-Bus(es)” be renamed “IO Bus(es)” which is what they really are?
Admittedly, Qtractor's input / output buses have many advanced features including the insertion of effects plug-ins, gain controls, etc..
Traditionally, Send-Buses (also known as Aux-Buses) are used to re-route track signals to;
- effects chains which run parallel to the original tracks, or
- auxiliary tracks, whereby the original tracks are recorded for later re-mixing and the (parallel) auxiliary tracks are used for a live mix.
So far as I know, Qtractor's input / output buses don't allow for an alternative route within Qtractor other than for monitoring purposes, so perhaps renaming “Send-Bus” to “IO Bus” might make the behaviour more transparent...
Add new comment