Broken Record… Bus-to-Bus Routing

[Jacob]

To Messers Allen & Heath,

I’m not sure if you all noticed, but a certain competitor just released a firmware update to their budget console that allows full bus-to-bus routing. This is in a console that can be purchased for as little as $1,600 USD.

Is this technically unachievable in the dLive world? I’m seriously asking. This feature has been requested by the community for at least 5 years (see https://community.allen-heath.com/forums/topic/groups-within-a-group). I have to imagine that it’s either impossible for you from an engineering perspective or y’all just don’t care about it as a feature. In either case, some level of transparency about the lack of development here would be appreciated.

And for anyone getting ready to explain the work arounds, trust me, I’m already aware. But that is what they are… work arounds. Burning an input channel isn’t a real solution, it’s a hack. And I’m also aware of the latency implications…

Rant over. I know I sound like a salty complainer. Don’t get me wrong, I really love my dLive. But this feature is something that I’ve wanted since I got it though and I know I’m not alone. It’s just a bummer to see far less expensive consoles get the feature.

[Tobi]

That is because of low latency and mixing coherency.

A&H Desks are fully latency compensated and therefor the mixing procuces a coherent sound (without phasing issues). If you do Bus-2-Bus mixing, this would not be as simple.

Either you would loose coherent mixing, because some signal ways get “longer” than others, or the overall latency of the system would increase in case of using bus-2-bus mixing.

Yamaha for example gives this as options… you can choose, if Main or busses should be compensated or not. But that feature goes with the drawback of a much higher system latency. A&H has a in-2-out latency of less than 1ms, Yamaha is much higher.

And Behringer, to which you refer in your post, does not give an information about in-to-out-latency — at least not that I found. But in case they use the bus-mixing you should assume, that they either have a much higher latency or an incoherent mixing.

Best Regards,
Tobias

[RS]

Would be just great to have the OPTION. I believe the vast majority, wishing for this feature, would know how to deal with latency/incoherent mixes, cause we have to deal with it on any other digital console, too. Have they automated countermeasures or if you have to do it by hand.

[Jacob]

Hi Tobi. You’re right, the analog in to analog out latency of the system is an impressive 0.7ms. And I totally understand that they would likely have to kill latency compensation in order to allow bus-to-bus workflows. That is totally acceptable, in my opinion.

As RS said, it at least gives you the option to use that workflow. And I completely agree that if someone is looking for that workflow, they are likely aware of the caveats and understand how to compensate for them. The work around of routing a bus to a channel already breaks the latency compensation for that path, so we’re not really losing anything.

And for what it’s worth, there are several other workflows that invalidate the latency compensation too. Insert a Dyn8 onto a channel or bus? You’re now 4 samples out of line with other signals and latency compensation is ruined. Use external plugin processing on a path? Latency compensation ruined. Insert a RackFX unit on a path? Latency compensation ruined. Use the Ext In on a bus? Latency compensation ruined.

My point is that there are already many ways to break the latency compensation of the system, all with varying levels of disclosure. Giving engineers a straight forward way to route groups to groups with a documented caveat of broken latency compensation would be a win. It reduces the complexity by not having to route a group to a channel and then that channel to a group and it saves channels.

The whole reason I started this thread is to hopefully get someone from Allen&Heath just to clarify whether it’s something that can’t be done, something that they refuse to do, or something that they want to do, but it’s complicated and will take time. Again, all in light of the Wing consoles now supporting this workflow.

[Tobi]

Hi Jacob,
I was not aware, that Dyn8 breaks coherency… are you sure?

Best Regards,
Tobias

[andia]

+4samples

[SteffenR]

To say, that latency compensation is ruined while you insert a processor with 4 samples latency is very harsh.

Bus to bus routing would add much more time to the processing path, and it will get worse if you add another routing stage.
And the outcome is audible. 4 samples are not really audible.

[Jacob]

Harsh? Perhaps. But it’s also a fact. If you insert a Dyn8 on a source, it is no longer in time with other parallel sources. And 4 samples can produce not only a measurable change in two parallel sources, but also an audible one. Is it the worst thing ever? Of course not, it’s super minimal. But that’s really not the point I was trying to make. The point is that within the dLive platform there are already built in workflows that throw off the latency compensation. Adding one more way to “break” that compensation doesn’t seem like a real loss to me.

And what causes you to believe that bus to bus routing would result in “much more time”? I’m not saying it would be zero, but I would think it ought to be minimal since we’re not having to go through any analog to digital or digital to analog conversions. At the worst it would be the same as the current workaround of routing a bus back to a channel, right? I don’t have my console in front of me right now, so I can’t confirm, but I want to say that routing a bus to a channel produced approximately 30 samples of additional latency. And to be fair, that is almost 8x more than 4 samples! But it’s still very manageable. If you compensated every other path in that scenario, your in to out latency is still about 1ms, which is great. I will acknowledge though that this would likely depend on how many “layers” of bus to bus routing to had configured.

Example:
Input > Bus > Bus is going to be shorter than Input > Bus > Bus > Bus, etc…

[Brian]

“4 samples are not really audible.”

You are never going to hear the “delay” of four samples, but if you are sending identical audio signals through two different audio paths and one passes through a Dyn8 and the other does not, you ABSOLUTELY will hear the phasing issues created by the 4 sample delay on one of the signals. How much the audio signal is changed will vary from situation to situation, but there will be a clear audible difference between having the Dyn8 inserted and not inserted (ie having a 4 sample difference in latency vs having no difference in signal latency between the two identical audio paths).

Now this really ONLY matters when you have two identical signal paths with different latency times. It’s honestly pretty rare that you would have separate, but identical, audio paths going through your system. Using two paths for parallel compression (regular drum group vs drum “smash” group) is probably the most common scenario where someone might do this. However with the ability to dial in dry vs wet signal levels on every compressor on the DLive means there is little reason to actually set it up with two different groups (and waste the busses). It is very simple to assign a custom encoder knob to the dry/wet ratio of a compressor and use a single group with a compressor utilizing the dry/wet mix ratio.

However there is no need to “compensate” for using a Dny8 on audio paths that are not being duplicated. For example, if you want to add a Dny8 to some vocal inputs, but not others, that is NOT going to cause any issues even if the different vocal inputs then get routed/combined in the same vocal group. There also won’t be an issue with adding a Dyn8 to a vocal group, but not adding it to other groups, etc, etc, etc. Only when you have identical audio paths do you need to worry about the latency that adding a Dyn8 will cause if you add it to one of the identical audio paths, but not the other identical audio paths. In that case, you would want to delay the identical audio paths without Dyn8s by 4 samples.

[Jacob]

Totally agree, Brian. I do run a drum “smash” bus, but mainly because I prefer to use a fader for adjusting the balance on the fly. And of course, an easy way to align those two is just make sure you have Dyn8 inserted on both. Or as you said, add 4 samples of delay to the bus that doesn’t have Dyn8 inserted.

[Brian]

Yeah, that is by far the most common scenario where people run two or more identical audio paths. I realize that people have historically used the two group faders to get the ratio they are looking for between “smashed” and “unsmashed” audio and that an engineer might want to change this ratio a lot (song to song or even during some songs) which the two faders allow for. It is not wrong to set your system up like this.

However I also love how A&H offers the wet/dry ratio right on the compressor. I don’t believe many other manufactures do this, so it’s not surprising that people don’t embrace this method to mix the compression level of their drum group. You can still go between 100% dry (ie regular) to 100% wet (ie smash) and anything in-between, but you’ll adjust that encoder instead of the two group’s faders. With DLive and Avantis, you can customize the GUI to assign this compressor ratio setting to one of the custom hardware encoders located on the right side of the screen(s) so that it is quick and easy to adjust that wet/dry ratio at any moment in time. In other words, you can change the ratio via the physical encoder knob without having to be on the right compressor screen to change it.

Again, there is no right or wrong way of doing it, but by using the compressor wet/dry ratio instead of two “parallel busses”, you do two things: you save a buss (or two if stereo) and you can’t “mess up” the latency because there is only one unique audio path, not two.

It’s just another potential way of handling it…….

[SQuser]

> … by using the compressor wet/dry ratio instead of two “parallel busses”… you can’t “mess up” the latency because there is only one unique audio path …
That’s what I expected.
I haven’t tried it with the MultiBD4 on Avantis yet, but I was disappointed that it’s not like that with the SQ.
If Slope = 18 or 24, I get a big comb filter effect with wet+dry – also if all 4 filters are off.

[RS]

@Brian if bus to bus routing would only be used for parallel compression, I would be totally with you. But that is not the point for me. I am looking for more summing options, when needed/suitable.

[RuneS]

This is generally what I’m seeing when this comes up.

Of the users asking for this feature:

70% wants to do a seperate band + vocal bus. You can already do that on dLive.

25% wants to do some sort of drum channel summing. Some of it (like combining two kick mics in a bus and send it to a drum bus) is already possible. Things get more complicated when you have several busses that need to go to that drum bus. You can do work arounds, and if you have it setup in you show file it is actually not that big of a deal…but it is of course something that costs more channels and busses.

5% wants to do more complex routing. (I for one would like to combine 1st and 2nd violins in a ‘violins’ group and have that go into a combined ‘strings’ group and the on to an ‘orchestra’ group…and that is a whole mess)

Personally though…I’d rather be able to unmute a channel that is DCA muted, write protect show files, or have actual stereo compression when ganging channels etc. But thats just me…

[RS]

@RuneS that’s not just you!
But individual ranking to me is impossible/useless the way A&H is handling suggestions here. And they don’t seem to want to change that, as it was stated elsewhere.

[Author]

Posts