Group to Group routing, please!!

[SteveParticipant]

dLive owner/user since 2017. Absolutely love the system and have converted several touring friends to the dLive platform.

The number one ask from people I know and work with: Group to Group routing capability, without having to route it to a matrix or an IP.

2 kick channels into a kick group, into a drum group, into a band group. It’s commonplace on other systems, and when A-list engineers discover they can’t do it with the dLive, they give a snarky response… yes, the uberfast latency would be impacted. But in nearly every live environment, 2.1ms or 1.4ms or whatever it works out to be is going to be acceptable.

Please, please, please add this capability. The system is so nearly perfect; adding group to group would help carry the dLive into the real “big boy” playing field.

[SteffenRParticipant]

Group to Group “patching” is already possible. It works with the external in at the busses.

I know it’s not the same as the requested feature, but sometimes it’s helpful to know a workaround.

[RuneSParticipant]

Its not ‘commonplace’ when only a few systems can do it without using inputs or matrices.

That being said you can certainly go:
Kick group>Drum group>Band group, by using the external in on each group. You will however not be able to send multiple groups to the band group. Just the drum bus + all the channels.

What I do is use the main bus as a band bus. I then route all vocals to a group and add that group to my output matrices. EazyPeazy

[andiabwaertsParticipant]

but could we do it with a matrix inbetween and send that matrix to the external in of the next group down the line and so on?

[BrianParticipant]

I agree that group to group routing would be extremely helpful and it would be great if A&H added it.

While the user would have to account for the added latency, that would be OK. Since the overall system latency is only .7ms which includes the A->D and D->A conversions, the added latency of just routing through a second group should be much lower than that.

[DaveParticipant]

+1

As long as you aren’t double-bussing, I don’t think the extra 1/4 or 1/2 ms of latency would matter for FoH. A note in the manual about group-to-group routing not having latency compensation would be fine, IMHO. Or go ahead and delay everything else to maintain the compensation… that’d be fine by me, too.

[Carl NParticipant]

Simple solution here is to use groups patched to input channels… Kick group is patched as the input to a channel called “kick” … this is then routable to a drum group… then assign that group to a pair of inputs channel called “drums” etc…

This is fairly common even on a console that allows group to group routing as it is generally the most flexible setup.. phase coherency is of course not maintained in this setup so you need to be careful with parallel routing etc.

[Author]

Posts