Routing Issue with Qu-SB and AR2412

[poppiesParticipant]

I’ve greatly enjoyed using a Qu-SB connected by dSnake to an AR2412. However, I’m a little lost in how to route some signals.

Currently, a signal plugged into socket “1” of the AR2412 shows up by default in channel “17.” This is fine, but it means I can’t seem to send anything to channels 1-16 from the stage, only from the Qu-SB sockets. It also means sockets 17-24 on the AR2412 are currently useless, and I’d love to use them and route the signals to channels 9-16.

I can’t seem to find any routing matrix or channel source combo that accomplishes what I’m attempting, so I’d appreciate any ideas. A great bonus would be to describe how to do this in Mixing Station, as that is the app I’m using to control/route.

Many thanks in advance.

[KeithJ A&HModerator]

@poppies

Remote audio units like the AR2412 use the dSnake protocol to connect to the mixer.
With Qu, you can then decide which sockets from dSnake will be patched to each channel when that channel’s source is switched to dSnake from the processing > preamp screen.

The dSnake input patching is explained in the user guide here –
https://www.allen-heath.com/media/Qu-Mixer-Reference-Guide-AP9372_10.pdf#page=72&zoom=auto,-273,645

It’s possible to patch any input socket on the AR2412 to any, or even multiple, input channels on the Qu 🙂
Then by pressing the Fn key in any preamp screen to show all sources, to choose whether each input channel is being fed by local (built-in), dSnake (remote) or USB (USB-B or Qu-Drive).

Cheers,
Keith.

[poppiesParticipant]

@KeithJ_A&H

Thanks, Keith. I know this is outside of your support area, but as best I can tell, it sounds like this is something that can’t be done in Mixing Station, and I’ll have to do it via Qu-Pad; does that sound like a possible explanation for my issue?

[poppiesParticipant]

The support folks from the local U.S. distributor walked me through the solution today, so I thought I’d share in case anyone in the future may ever need the info.

The biggest confusion on my part ended up being that with a Qu-SB / AR2412 setup, the routing matrix has a sort of invisible dividing line between row 16 and 17, where the first 16 rows represent by default the Qu-SB sockets, and rows 17-32 represent by default sockets 1-16 of the AR2412. Of course, this important invisible dividing line isn’t documented anywhere that I’ve seen.

In my case, I wanted to route the signal from socket 17 of the AR2412 to channel 9 of the “virtual mixer.” To do this, I had to move the marker in row 9 of the routing matrix to column 17 as the first step. I then needed to set the “source” of channel 9 to “dSnake” instead of “local.”

In retrospect, this all makes sense, and I don’t know if there’s some great way to make it clearer other than maybe documenting the division line in the routing matrix.

If anyone ever needs help with routing, feel free to message me now that I have a clue!

[poppiesParticipant]

Also, I should note this issue didn’t end up being specific to Mixing Station at all; Mixing Station very faithfully recreates the somewhat confusing routing matrix from the Qu-Pad software, so one simply needs to somehow know how the rows and columns are divided between your devices.

[KeithJ A&HModerator]

@poppies

I’m not fully sure what you mean regarding an ‘invisible dividing line’ in order that we could explain it better, either in documentation or through a knowledgebase article that may help others.

The Qu-SB has a Qu-32 core, so it has 32 input channels, the first 16 of these channels are sourced by default from local inputs and have the option for local, dSnake or USB sockets for sources, then channels 17-32 can be sourced only from dSnake or USB (they have no associated local input socket).

The reason that the default is to have channels 1-16 sourced locally and then 17-32 sourced from dSnake 1-16 is because the most common way to expand the Qu-SB is either through addition of an AB168 or maybe an AR2412. In which case, you’d usually use the input sockets on the Qu-SB AND the input sockets on the expander and both would be on the stage.

So there is a difference between input channels that can be sourced locally and those that cannot, but as any channel can be sourced from dSnake, it would not make sense to indicate this difference on the dSnake input patch screen.

Very glad to hear you got it all working as required btw!

Thanks,
Keith.

[poppiesParticipant]

Keith, I think it would be difficult to make things more clear, but I note as a start that the column headers in the matrix are all labeled as dSnake, but by default as you mention the first 16 sockets are local and not really “dSnake.” Perhaps A&H thinks of all sockets as part of a dSnake continuum, whether they utilize a dSnake linking cable or not.

[KeithJ A&HModerator]

@poppies

Perhaps the confusion is because it’s a two step process?
1) In the dSnake input patching matrix, you are patching sockets from the dSnake connection (i.e. any socket on any connected digital expander/stage box) to the optional dSnake input of any input channel.
2) On a per-input-channel basis, you are then choosing whether to use the local (fixed), dSnake (that you patched) or USB (fixed) input ‘type’.

So it’s a perfectly valid operation for example, to patch dSnake socket #3 to the dSnake option for input channel #8, and then switching the source of input channel #8 between local and dSnake just switches between local input socket #8 and remote input socket #3 on the connected expander.

Another way to put it is that all dSnake patching is always active, even if input channels are not making use of it.

I’ve attached a diagram to indicate where the input patching ‘lives’.

Cheers,
Keith.

Attachments:

You must be logged in to view attached files.

[Author]

Posts