Main menu
You are here
Still trying to understand routing possibilities
Routing has been a bit of a moving target for me. For years I outsourced everything to Carla over many MIDI and audio buses.
Then I switched to pulling the plugins back into Qtractor and only using Carla as a bridge by way of placeholder buses to serve as over-glorified bridges.
More recently, I eliminated Carla all together by leaning into Carl Irwin's most excellent routing pattern making heavy use of Inserts. So far, this has been the best pattern as everything is quite clear but it does have some drawbacks in terms of creating inserts and chasing after then (output port assignments) each time a new track is added. Some people here know (and probably use) this workflow and would recognize it by the steps involving renaming the native Master bus to IGNORE and creating a new Master bus sitting at the end of the chain.... yada yada.....
Which brings us to today.... Rui has done a bunch of work recently which essentially decouples the baked in Master and there's been much discussion as of late on how to tap into all the routing possibilities by way of Aux Sends. The thing about these Aux Sends of course, is that they are (still) pre-fader which means the signal is forked before it has a chance to be influenced by a strip's volume slider, or pan.
Essentially, the usable area of a bus strip with an Aux Send is reduced to this:
OK, that's fine. We understand an Aux Send makes a copy of the signal and ships it pre-fader. So we want to come up with another means to impact the audio signal with a bus' gain and/or pan sliders. Here, I've added a 2nd track called Synth 2 which has its Audio assignment assigned to the Synth 2 bus. That bus is sending output to a Audio Insert placed in the first slot of the MixDown bus. The important thing here is that the Synth 2 bus is panned hard. We can see only 1 channel is being output.
To my surprise and dismay, soloing this track produces signal straight down the middle.
So I'm either entirely dumb (possible) or something is not happening that should? It just seems like it shouldn't be this difficult to route and manage signal across a mixer. I'll attach the .qtz if anyone is interested in poking at it.
One thing I should probably also mention is I've been very consistent about NOT trying to mix (volume and/or pan) using the Track strips. The reason for this is I work nearly 100% with MIDI and therefore, really don't benefit from those sliders in the way that people who work primarily with audio do.
Thanks in advance.
| Attachment | Size |
|---|---|
 output-strip-aux-usable.png | 8.38 KB |
| mixdown-with-ins.png | 36.36 KB |
 AuxSendWithInsert.qtz | 3.97 KB |
I've been testing more and it
I've been testing more and it seems to me Inserts can no longer be used to construct a workflow as outlined in Carl Irwin's video. I can get BUS1 to output to BUS2/Input1 but can't get the signal to hop again by sending BUS2's outputs to BUS3/Input 2.
re. Still trying to understand routing possibilities...
for ages I've always advised for not doing send/return inserts from and to qtractor itself: it used to work just partially and on very specific situations, while using *genuine jackd1 or jackd2; but on pipewire-jack substitution, things got a lot different and to the worse: while it used to work fine on all scenarios a few releases back (pre-1.0.0 iirc.), it stopped working on-and-off or not at all on newer versions.
so the writing is still on the wall: directly connecting a same jack-client (qtractor) output ports (insert sends or output buses) to its own input ports (insert returns or input buses) is still not advisable.
just a few topics on the subject, even predating the pipewire advent:
not sure whether pipewire also does the so called zero-copy optimization as genuine jackd; you may confirm it, by connecting any other client but qtractor to the designated inputs and check for your self whether the signal starts flowing in...
seeya
AuxSends post fader is posible in Qtractor
Hi @windowsrefund:
"The thing about these Aux Sends of course, is that they are (still) pre-fader which means the signal is forked before it has a chance to be influenced by a strip's volume slider, or pan."
AuxSends post fader is posible in Qtractor. You just have to create a new PAN and GAIN with plugins.
It is true that with sends the original PAN and GAIN faders are just decorative, but that does not mean that you cannot create workflows with post-fader sends.
I will return your file with the configuration that I use.
In addition to a send, always a PAN and a GAIN with plugins.
Hi G3N-es,
Hi G3N-es,
So I see the work-around here. You're processing the signal before it leaves the track. I've done that previously with the
Audio Gainlv2 plugin as a work-around which is nice because then each of these play nicely with a track's automation lanes. I just never thought about using theCalf Stereoplugin like this. Very clever.I'm curious though... why did you add both the gain and pan plugins to the buses as well? For example, on the
Synth 2bus? They don't have any effect whatsoever.Because every send must be
Because every send must be post-fader. Imagine I send a reverb bus to a mix. When I do it this way I see the real gain I'm sending reflected in the VU meter, and if I pan it the same. If I use the send control directly, I won't see the send signal reflected in the VU meter.
In other words, if an Auxsend must always be post-fader, we must always insert a Pan and Gain fader before the auxsed.
We may not need it, but it's there in case we need it. It's how I configure my template.
I think you're just saying
I think you're just saying the redundant plugins aid in signal visibility. I can appreciate that but I don't know why you're saying this is a
post-faderstyle workflow. if we look atTrack 2, the track's fader doesn't impact the signal nor does the fader on theTrack 2bus. All we're really doing here is kind of hacking around thepre-faderlimitation by manipulating the signal with (redundant) plugins before moving it around. Am I missing something?Yes, you're missing something
Yes, you're missing something.
Imagine track 2 sending to Reverb.
If you lower the gain from the original fader, the wet gain will be proportionally increased as the dry gain is lowered.
If you do it from the send gain, you modify the wet gain, but not the dry gain.
However, if you follow the post-fader flow and use the gain from the plugin, the signal will behave as it should. Both the dry and wet signals are decreased equally.
I say it's a post-fader workflow, because it really is.
With all due respect, I think
With all due respect, I think we may have different opinions on the definition of these
preorpostterms as it relates to the fader. For me, in order to qualify aspost, the fader in question must be able to impact the signal. If the signal is being rerouted before the fader has a chance to impact it, it's apre-faderwork flow.But what I'm trying to tell
But what I'm trying to tell you is that Gain is the new fader. The original fader and pan in qtractor are ignored because they no longer make sense. (Something similar to what happened with the default Master).
It would be nice if both the fader and the pan and even the VU meter were movable plugins in the plugin box, as happens for example in NonMixer.
But that would only make sense for audio buses and tracks.
What about MIDI? If they support MIDI and audio streams, should they also have audio plugins?
And if so, would the layout of the MIDI tracks and buses also have to be changed?
Too many problems to solve for something that would not really improve the workflow.
It would simply prevent the original faders from no longer making sense.
In the end we would have movable plugins, something we can do now with external plugins.
It would be cool if the
It would be cool if the faders and pans could be switched to a "controller only" mode to mimick themselves as automation source to control plugins. Then we could control an amp plugin and a pan plugin with those faders.
Placing an Aux oder Insert Send or a plugin before them is Pre-Fader, after them is Post-Fader.
I don't give up hope :)
What you say sounds like a solution
But some kind of visual marker would also have to be created.
not bad, not bad :)
not bad, not bad :)
That would certainly be
That would certainly be interesting though I still have doubts on whether CC values of 0-127 translate well for working with gain. I remember reading a post somewhere on this forum explaining how the resolution (128 increments) doesn't really translate as well comparatively. I'll step back and let those more knowledgeable on the subject get into the details.
The gain 0 value is determined by the plugin
The fader would remain as a neutral slider as it is now when we assign a shortcut to the plugin.
Different plugins place the gain 0 dB point in different places.
This can certainly be confusing, but it is something that already happens as you can see in the gif.
Of course the lower box of the fader would indicate the value returned by the plugin, it would not do so in dB.
Looking at it more closely, I
Looking at it more closely, I find it complicated, unintuitive and confusing :S
I'll stick with the current option. Ignore the default faders.
Another note.
Another note.
I use the Calf Eq as gain because it gives me decibel values (at least in the GUI), and I feel more comfortable with it than with the 0 to 4 range value that the Gain plugin offers.
Another advantage is that I already have a prepared Eq, which is usually needed most of the time. As for performance and consumption, if you don't have the Eq bands activated, it consumes the same as the Gain plugin. So for me with this configuration it's all advantages.
Can totally appreciate that
Can totally appreciate that :D
Hi Rui,
Hi Rui,
I'm a bit surprised as I thought we realized we're not talking about the classic BUS1/out -> BUS2/in voodoo badness. We're talking about using inserts as a middle man which worked flawlessly up until recently. Is this the first time you're reading about that approach?
using inserts
But it's not necessary to use inserts to redirect signals to internal buses.
AuxSends work better. Take a look at the file I posted above.
Inserts Qtractor > Qtractor, are still useful if you want to use a track as if it were a bus.
It's not a recommended workflow and you also have the problem of delay.
Now that I have a functional way to automate buses (with CC), for me, using tracks as if they were buses no longer makes sense either.
re Inserts, again...
ALL send/return Inserts are processed externally, either by genuine jackd or pipewire-jack implementations, whatever is in service.
otoh. only aux-sends are indeed internal and under full qtractor's control.
there's no way or hope the flaws of the external inserts will ever get fixed in qtractor alone, present or future wise.
please, read again the writing on the wall.
cheers.
Looks like I'll have go back
Looks like I'll have go back to using Carla as a middle-man then because at the end of the day, it's critical to be able to get a signal to pass from BUS1/outputs to BUS2/inputs. Here's a perfect scenario explaining why this is is so important. Imagine you have a multi-out drum plugin (not uncommon for drum synths). Of course, many plugins have multiple outputs but we'll just use a 16 out drum plugin as an example. The goal here is to isolate as needed. For example, maybe the kick is outputting to stereo out 1, the snare to stereo out 2, HH to stereo out 3..... and so on.
So you start by creating output bus with 32 channels and then point your drum track to the new bus. Drums are coming in on their respective channels and things are looking good.
Now you decide you want to work on the snare sound. Maybe you want to work on the transients or add a delay. You have to be able to isolate that stereo channel in order to do that work. This can't be done without routing that exact pair of channels to another bus where it can be processed.
Now what's a little alarming is that up until the recent "xaudio" work (I don't know what to call it), input sends were working exactly like they should. The key word there is "should". From all my time in the world of Qtractor though, there has never been any well-established means of routing a signal from a given bus' output to another bus' input. Essentially, the entire issue is treated as some kind of "ghost in the machine" but........ what other mixing console treats signal routing in that fashion? Being able to route an output to an input is kinda the bread and butter of how a mixer is supposed to work.
It's just frustrating having material (sessions) break because there's a lack of willingness or even curiosity to get a mixer to act like an actual mixer.
I hear what you're saying about Insert Sends being offloaded to the underlying audio engine but please remember, from an end-user perspective, nobody cares. All we're trying to do is route a signal from point A to point B. How that happens (in a reliable fashion) is kinda besides the point. I mean, a bus input is within Qtractor's codebase as is a bus' output. Remember, the whole "using Input Sends to work-around the mysterious bug" thing isn't really the goal. It's just a work-around that worked....... until it didn't. Honestly, it really should have never been needed in the first place. It should be possible to route directly from a pair of outs to a pair of ins but I think we all know this reasonable expectation has long been abandoned for reasons unknown.
re. Looks like I'll have go back...
let's put this way, for the layman to understand:
the issue is not fixable on the qtractor side, and most prolly never will. sorry.
please resort to whatever means you were doing way before--I even don't know how you got the idea that it was ever solved--maybe you were deceived by it seemingly working under pipewire for some time, on-and-off perhaps, but well, what can I say, caveat emptor?
cheers
Aux Sends are pre-fader
Aux Sendsare pre-fader though so you lose (as mentioned above) the ability to control gain and pan.Update: Oh damn, I didn't even see your original response with the attached .qtz. I'll check that out immediately. Even if it does work, can we all just admit it's a shame that we end up with so many volume and pan sliders that are essentially not usable? It's like half of the mixer itself (and the screen real estate used) becomes essentially worthless. That said, I'm gonna check this out!
Add new comment