Forum Replies Created
-
AuthorPosts
-
2021/09/14 at 6:24 pm #103435
I would recommend not selling your existing system until you have your new system on hand. There is a global supply problem for electronics in general, with specialty products (such as audio consoles) being very hard hit. Here in the US lead time is weeks to months (I just finally received another DX168 that I had ordered 6 weeks prior), and I don’t see much in the way of relief this year at all.
2021/05/13 at 4:05 pm #101313I’ll have both Surfaces back out for testing before long and will be working with it more. There are numerous other things still to sort with this mode before we roll into a live gig with it.
2021/05/12 at 6:09 am #101279It works not that way… again… the idea is to have both (all) surfaces on trim during the show, even the director instances should switch to trim in this case…
Why would I want my monitor engineer, who is supposed to be controlling the pre-amp gain in this scenario to switch to trim for show? The *entire* point of Gain Tracking is so that whoever has the head amp gain control (in this case, the monitor engineer) can make adjustments to the pre-amp gain, and the other engineer’s trim automatically compensates. Having the monitor engineer have to make an extra step to get to the pre-amp gain during show is just silly.
One could try and make the argument that “whatever adjustments need to be made during show can be made in Trim for all concerned”, but that’s a preference.
And honestly, the core issue is a setting that should be relative to one Surface (Surface Role: FoH) and its channels (1-64) should not be forced on another Surface in a different Role (Surface Role: Monitors) using channels 65-128. This behavior nuance is certainly not intuitive, and after a read through the Firmware Reference Guide, The Understanding Multi-Surface Mode document, and a scrub through the knowledge base, does not seem to be actually documented anywhere.
It would be great for Allen & Heath to chime in here with the -official perspective- – @nicola @keith @ben et al – care to weigh in here?
2021/05/10 at 9:42 pm #101234I also expect it to only affect the channel range selected. If I select channels 1-64, which are the FoH channels (with channel sources Rack 1-64), why would it change channels 65-128 (also channel sources Rack 1-64) on the other Surface? This is a setting of what the Surface controls (pre-amp or Tirm), and should be individual to the Surface.
Correction here – the channel start and end on that screen is labeled specifically for Gain Tracking, so a poor assumption that it would limit the effect of the buttons above it (Enable Preamp on Surface & Disable Preamp on Surface). However, I stand by my thought that these buttons should only affect the local Surface, not all Surfaces connected to a system.
2021/05/10 at 9:25 pm #101232I understand how you access pre-amp gain when you have the Trim on the surface. This is not the issue.
The issue is that a Global Surface option (setting either the pre-amp gain, or the trim on the Surface using the setup button on the surface and tapping the pre-amp area), instead of affecting the Surface it’s set on only, affecting all Surfaces in the system.
I also expect it to only affect the channel range selected. If I select channels 1-64, which are the FoH channels (with channel sources Rack 1-64), why would it change channels 65-128 (also channel sources Rack 1-64) on the other Surface? This is a setting of what the Surface controls (pre-amp or Tirm), and should be individual to the Surface.
The only way to disable the pre-amp on the Surface and have trim only, without it affecting the other Surface, seems to be you have to set it one channel at a time.
I would note this behavior is not called out in the Multi-Surface document, hence why I am asking if this is really the intended behavior (have Surface options on one Surface in a system overwrite option on another)
2021/05/10 at 3:47 am #101209What did I expect? I expected it to take the pre-amp gain off the Surface that I executed it on (the FoH C2500), not both Surfaces that are configured for different roles.
The idea is that during sound check, the Monitor Surface sets the pre-amp gain, the FoH Surface uses Trim. At the end of sound check, the FoH Surface sets Gain Tracking to “on” so if the Monitor person makes a gain adjustment for the monitors the FoH trim is adjusted proportionally to so it doesn’t affect the FoH mix. Only one person ever adjusts pre-amp gain itself in this mode (monitor engineer in the scenario I am working in).
So again, is it really expected that this affects both Surfaces connected to the system regardless of their assigned roles? This smells like a bug, honestly.
2019/10/17 at 6:58 pm #87124+1 for more additional Matrix outputs.
I would even be fine with having an option that takes 3 of the other busses and turns them into additional Matrix outputs…….
2019/10/16 at 7:49 pm #87094@tjcornish – That’s correct. Avantis SLink Port —> DX Device –> GX device will not work – the SLink port goes into DX mode, which only carries 32 x 32 channels. Avantis SLink Port —> GX Device —> DX Device will as the port goes into GX (GigaAce) mode and carries 128 x 128.
2019/07/01 at 9:12 pm #84953You can, but YMMV as not all switches are equal. I would configure a port on each switch as an access port for the VLAN you want to use, make sure it’s trunked on the links between the switches, and turn Spanning Tree off for that VLAN if your switches will allow it.
Bear in mind that this is not officially supported by Allen & Heath at all, and may or may not work.
You certainly *do not* want to tunnel L2 over L3 for DX or GigaAce as you will almost certainly introduce timing issues with the added encapsulation/decapsulation required.
2019/06/05 at 2:15 am #84336I’m sure it’s been said before, but I’ll say it anyway – this is *exactly* why you should never have auto-update enabled on tablets or computers used for production work. If you do, sure enough, you’ll get bitten by this exact scenario sooner or later.
2019/05/30 at 6:00 pm #84156@nicola – Is a dedicated offline editor still in the works, or is the development centered around the MixPad application only? (Or, can you not say – which I will understand of course)
2019/05/30 at 5:57 pm #84155I have to agree – De-esser as a DEEP plugin would be of greater value and use than solely as a FX Rack unit. Totally understand why the others could not be implemented as DEEP due to the lack of the DYN engine on SQ, but hopefully we can get the De-esser as a DEEP plugin in a future release.
2019/03/07 at 9:17 pm #82493The “Redudndant/Cascade” switch being somewhere much more accessible (like on the front!) would be extremely useful.
As for squeezing into 2U of space versus 4 – I imagine it could be done, but looking at what I can see of the different boards through the vent holes, I would imagine it would be a complete redesign, and a challenging one at that.
Still, a 2U version of a DX168 would be pretty awesome.
+1
2019/03/07 at 9:04 pm #82491+1 for db levels on the scribble strips.
I love the “fader jump to 0db or -inf” ability (I use it all the time), but levels on the scribble strips would be very useful.
2018/12/20 at 10:53 pm #80976+1 for this – My SQ-7 arrives tomorrow – I’d definitely pickup the compressor and GEQ packs on Boxing Day if they were on sale!
-
AuthorPosts
