X32 Discussion

Re: Delay not working

I think I have a bug. I mentioned it earlier and thought I found the problem but it has still persisted. Sometime when I start up the console, the delay effect does not work. All the routing seems to be fine, and the buses page shows that signal is going to the effect, but when I switch to the effect page, the delay shows no signal passing through.

I have checked all the routing and am losing my mind over this. Let me know what I'm doing wrong.


Check your effects bus master fader on the bus layer. It should be up. I recently had the same "problem" :razz:
 
Re: X32 Discussion

Hi.

Seem to have hit a fairly major issue with our X32 on Saturday night.

About 7 hours into a gig the faders for matrix 1&2, which were linked together, started moving with a life of their own. Movement wasn't a gradual creep, but sudden jumps of +/- 10db or more. As the FOH system was being driven from Matrix 1&2 this was pretty serious!

Ended up with the engineer having to ride/fight the faders back to unity. Unsure if anything else was effected than the matrices as we couldn't swap layers on the send bank to look, without losing control of the matrix...

We unplugged the network cable from the router, to remove the possibility that the X32 was receiving spurious wireless data, with no effect.

We then resorted to a full power cycle of the desk, which also didn't resolve the problem.

Desk was well ventilated and felt cool. Power wise was driven from 240v UK mains with a UPS inline, so am fairly sure that's not the problem.

in the end, as the quickest way to resolve this, as this was the final act and they were an electronic act sending a single stereo feed, we ended up just bypassing the desk and plugging their input straight into the FOH system. The desk then was left to continue to run their monitors off a couple of aux sends.

Not sure I can trust the desk again until we get to the bottom of this - this would have been catastrophic if this happened while running monitors for a live band...
 
Re: X32 Discussion

Hi.

Seem to have hit a fairly major issue with our X32 on Saturday night.

About 7 hours into a gig the faders for matrix 1&2, which were linked together, started moving with a life of their own. Movement wasn't a gradual creep, but sudden jumps of +/- 10db or more. As the FOH system was being driven from Matrix 1&2 this was pretty serious!

Ended up with the engineer having to ride/fight the faders back to unity. Unsure if anything else was effected than the matrices as we couldn't swap layers on the send bank to look, without losing control of the matrix...

We unplugged the network cable from the router, to remove the possibility that the X32 was receiving spurious wireless data, with no effect.

We then resorted to a full power cycle of the desk, which also didn't resolve the problem.

Desk was well ventilated and felt cool. Power wise was driven from 240v UK mains with a UPS inline, so am fairly sure that's not the problem.

in the end, as the quickest way to resolve this, as this was the final act and they were an electronic act sending a single stereo feed, we ended up just bypassing the desk and plugging their input straight into the FOH system. The desk then was left to continue to run their monitors off a couple of aux sends.

Not sure I can trust the desk again until we get to the bottom of this - this would have been catastrophic if this happened while running monitors for a live band...
Ouch!

I'm curious - Is this reproducable if you load a different scene and link those two matrixes again?

I'm thinking two scenarios. Either corrupt scene data or 'following faders' due to linking.

With following faders I mean - Fader two thinks that fader one moved a notch (but it didn't) and then fader one sees that movement and moves since fader two did due to them being out of sync. This will then repeat endlessly. Since you already had previous issues with your faders (or was it the other guy?) this is most likley the cause...

Leaving the matrix layer would verify this and can be verified with xcontrol. This also goes for the previous aux issue where the issue appears when entering the aux layer.

I'm not at my console at the moment but I believe that you can unlink faders while still having the channels linked. This can also be used to verify this issue.

Good Luck and keep us posted!
 
Re: X32 Discussion

Must have been someone else who had problems with their faders...

I'm going to raise a support call with Behringer this morning.

Am also going to see if we can replicate the issue in the workshop...
 
Re: X32 Discussion

Must have been someone else who had problems with their faders...

I'm going to raise a support call with Behringer this morning.

Am also going to see if we can replicate the issue in the workshop...

These things are not unheard of with digital mixers costing ten times more, so it was bound to happen I guess, but worrying still.
It would certainly be good if some future updates could include options to disable faders or rearrange fader and channel assignments so that instead of physically linking faders, fader channels could be paired or grouped to only be present on one fader. It might not be obvious when everything is new and totally functional, but real life usage sometimes tells us that dependancies that were ok on the drawing board are not safe in real life.
I prefer to link while setting up stereo pairs to get the effects and eq paired, but I generally unlink before a performance because I still have the (analog) habit of pushing both faders of a stereo pair.
 
Re: Delay not working

The buss master is up. I use the buss master to ride the delay during a gig.


DO you always use the same scene Kev, or have you switched scenes? - I know you said you confirmed routing, but you;ve double checked your "in path, and out path", and the effect is "on"...
no mutes enabled
no dca routed enabled that you might not have up...

all this talk of "faders issues" kind has me glad I'm using my ls-9 friday night.. :(
 
Re: Delay not working

No fader issues on this end, the board doesn't like it if you grab both faders in a linked pair. Simple solution, don't grab both faders.

I don't have any fader issues either, cause I don't link stereo faders, I just grab both, or assign them to ONE dca fader...
i'm just commenting that I hope this isn't the behringer of old creeping up.
I have one of my desks installed, and I have my second one at my house, awaiting the 10PM call that something catastrophic has happened to console 1... don't get me wrong, I hope that call never comes but.....
 
Re: Delay not working

I don't have any fader issues either, cause I don't link stereo faders, I just grab both, or assign them to ONE dca fader...
i'm just commenting that I hope this isn't the behringer of old creeping up.
I have one of my desks installed, and I have my second one at my house, awaiting the 10PM call that something catastrophic has happened to console 1... don't get me wrong, I hope that call never comes but.....

I hear ya Shane. We can all agree that we are inevitably going to see some failures, I can't imagine how many units are out in the wild already, I'm sure by next summer we'll start to get a real idea of this consoles impact on the market. I just hope that when units start to fail, whether due to manufacturer defect or end user error, hopefully we can keep the "zomg behringer!" comments in check and look at it under the same lens we look at more expensive digital consoles.

Time will tell, I'm loving my X32 thus far.
 
Groups vs. Mix Buses

I'm reading through section 5.9 of the X32's user manual and I'm wondering if I am understanding correctly.

Would it be correct to say that a sub-group (as implemented in the X32) is the same as a post-fader mix bus with the each channel's send level set to unity?

If so, why use a sub-group when
a) it still uses one of your available 16 mix buses,
b) you no longer have the *option* to control each level separate from the fader (i.e. the send level is strictly controlled by the fader; not the aux-send controls), and
c) you lose the *option* to send to the bus pre-fader (since according to the docs, the level follows the fader)?

Based on only those observations, it would seem a sub-group is just a post-fader mix bus with aux-sends set to unity.

I'm guessing I'm missing something. Most likely obvious.
 
Re: Groups vs. Mix Buses

I'm reading through section 5.9 of the X32's user manual and I'm wondering if I am understanding correctly.

Would it be correct to say that a sub-group (as implemented in the X32) is the same as a post-fader mix bus with the each channel's send level set to unity?

If so, why use a sub-group when
a) it still uses one of your available 16 mix buses,
b) you no longer have the *option* to control each level separate from the fader (i.e. the send level is strictly controlled by the fader; not the aux-send controls), and
c) you lose the *option* to send to the bus pre-fader (since according to the docs, the level follows the fader)?

Based on only those observations, it would seem a sub-group is just a post-fader mix bus with aux-sends set to unity.

I'm guessing I'm missing something. Most likely obvious.

no, i think that pretty much sums it up. :)

you may ask "why would i ever use the subgroup feature when i 'lose' options"? but if you really just want something to act like a subgroup and you don't want to have to set all the faders perfectly to unity post-fader, it's a handy shortcut.

FWIW, this idea [subgroups that switch-hit to be aux sends] is nothing even remotely new and has been implemented on many analog and digital consoles before the X32. which i think is fine. i lost any real use for subgroups when VCA consoles came into vogue, so using those buses as aux mixes was always MUCH more useful to me.
 
Re: Groups vs. Mix Buses - long and winding road

I'm reading through section 5.9 of the X32's user manual and I'm wondering if I am understanding correctly.

Would it be correct to say that a sub-group (as implemented in the X32) is the same as a post-fader mix bus with the each channel's send level set to unity?

If so, why use a sub-group when
a) it still uses one of your available 16 mix buses,
b) you no longer have the *option* to control each level separate from the fader (i.e. the send level is strictly controlled by the fader; not the aux-send controls), and
c) you lose the *option* to send to the bus pre-fader (since according to the docs, the level follows the fader)?

Based on only those observations, it would seem a sub-group is just a post-fader mix bus with aux-sends set to unity.

I'm guessing I'm missing something. Most likely obvious.

In addition to Brian's comments, consider that the subgroups allow you to perform processing on the summed audio of all the channels assigned to the subgroup. Here's a hypothetical example using vocal compression, and we'll assume that the console is being used for FOH only - no monitors or multi track recording.

On your vox inputs, use the channel strip's compressor to get the result you want for each singer. Assign the channels to a subgroup and NOT L/R. Insert a compressor (if it doesn't have one as part of the subgroup) and assign the subgroup to L/R. Bring up the background vocals and adjust the compressor so they just tickle the first gain reduction light (usually -1 or -2 dB) and then raise the threshold until it stops. Bring up your lead vocal and use it to actually 'hit' the compressor. It won't have to be much, or it could be a lot; that's an artistic decision you get to make... but this will help you keep a "space" between the lead and BGV. Another dynamics example are in the drum kit. The "arena rock" drum sound from the 1980s and 1990s came from lots of compression, reverb and some radical channel EQ... if the drum channels are assigned to L/R, also assign the toms to a pair of (or a stereo) subgroup to preserve any panning. The subgroup(s) get inserted compressors and are assigned back to L/R. Adjust compressor to give the kit a "bigger than life" presence. When the effect is not needed, you bring down the subgroup masters and bring them up when you do. Note that this is a Ye Olde Analogue Tricke and many digital mixers DO NOT compensate for the additional processing latency from the subgroup compressor. This creates an audible and generally unpleasant comb filtering. I don't know if the X32 has compensation, but the feature is important if you do anything where the same signal is routed to multiple buses, separately processed and then recombined. Almost-light speed analog doesn't present an audible problem but you'll sure hear it in digi-land.

An example of grouping for EQ reasons in youth theater... this is a "stock" design I use at the local PAC. Three AT853 hanging choir mics about mid-stage, for upstage ensemble pick up; 3 Crown PCC-160 across the apron (the back side lobe picks up the orchestra pit), 12-16 wireless body packs on the cast, keyboards and "spot" mics in the pit. The hangers, foot mics, and pit each get assigned to individual subgroups; cast wireless get at least 2 groups (men/women, or some such) and each subgroup gets an inserted parametric EQ. I "ring" each hanging mic gently to see if there are common feedback frequencies BEFORE I bring them up together... I use just a little channel strip EQ to help them sound the same, then use the subgroup parametric to get as much gain before feedback as I can. This allows the use of the input strip EQ to voice the individual mics. Lather, rinse and repeat for the foot mics, and the wireless stuff. Before any of this is done, however, I've done my system work so I'm not having to fight the PA at the input strip level... and that's a whole 'nuther post that isn't specific to the X32. At any rate, the outputs of the subgroups are routed where ever the need to go... L/R, matrix, etc and there is no "parallel processing" involved. With enough time it's possible to make 3rd graders audible to grandma in the back row. ;)

In general it's a good idea to consider your routing based on the result you want and work your way backwards through the signal chain.
 
Last edited:
Re: X32 Discussion

Ended up with the engineer having to ride/fight the faders back to unity. Unsure if anything else was effected than the matrices as we couldn't swap layers on the send bank to look, without losing control of the matrix...

Have you tested to make sure you would've lost control of the matrix? If it is as Robert theorizes:
Fader two thinks that fader one moved a notch (but it didn't) and then fader one sees that movement and moves since fader two did due to them being out of sync. This will then repeat endlessly.
(which I could think might be caused by something out of "alignment" between what I assume is the stepper motor controlling the fader and the sensor that detects the position of said fader) - this may not be an issue with unlinked faders, but with links then Robert may be right, it may be one fader detecting the position incorrectly, correcting the other one, and back and forth etc...

My point being, that if, after adjusting the faders back to positon to their desired location, you were to switch to another fader bank, then that matrix set would no longer be "controlled" by the faulty faders, would it? (Until you have to go back to that page...) This would be something to try, just to help determine where the problem lies, I would think...

Also, can you not reassign Matrices 1&2 to a different set of faders without having to reconfigure the sends to the matrices? Or are those not as assignable? (Thinking something that could've been done to get you through the gig).
Another idea that I'm not sure if it would work since I haven't seen the interaction between the X32 and the xcontrol, does the selected layer on the board always follow what is selected in xcontrol? Or could you select on of the other two layers on the board and keep the Matrix layer selected on xcontrol to keep tabs on it?

I realize these are all moot points right now since the gig is over and there is a support request in, I'm just thinking through in my mind how this could've been worked around during a show where this started happening. (And also completely realizing that these are things that shouldn't happen but do... As someone else said, this happens on mixers 10x the price of the X32, so I don't blame Behringer for this... As a programmer in my spare time I'm very aware of how bugs can happen at the least expected and most inopportune time)
 
Re: X32 Discussion

Can't say that I've had problems with the faders on my X32, but I don't use the matrices.

I do have a question about show files on USB sticks.
I used my X32 with a regular band, and I have a complex show file with FX routings, Ultranet, etc.
If I save that to a USB stick and load it in to another console, will EVERYTHING come across?

I'm gigging at a venue this weekend that has an installed X32. They don't have their Ultranet set up, but I have a Cat5 reel that I will run to the stage.
It's been a while since I've had a white glove gig, so I'm hoping that all settings are transferrable.

Does anyone have any experience of this?

Karl.
 
Re: X32 Discussion

Have you tested to make sure you would've lost control of the matrix?
...
My point being, that if, after adjusting the faders back to positon to their desired location, you were to switch to another fader bank, then that matrix set would no longer be "controlled" by the faulty faders, would it? (Until you have to go back to that page...) This would be something to try, just to help determine where the problem lies, I would think...
Yes, this is the essense of my previous post

Also, can you not reassign Matrices 1&2 to a different set of faders without having to reconfigure the sends to the matrices? Or are those not as assignable? (Thinking something that could've been done to get you through the gig).
Another idea that I'm not sure if it would work since I haven't seen the interaction between the X32 and the xcontrol, does the selected layer on the board always follow what is selected in xcontrol? Or could you select on of the other two layers on the board and keep the Matrix layer selected on xcontrol to keep tabs on it?
As far as I know you can only re-route physical inputs and not matrixes and subgroups.

The remote control is not dependent on the physical x32 control surface so you can have several remotes controling different things without disturbing the others. This means that any control surface can have exclusive access to any layer.

Given the setup options in the console one can keep channels linked but still have the faders (and mutes, since they share this option) not being a part of the linkage. This also helps in the cases where you slide your finger over the mutes and some channels won't become muted since the linkage prevents the finger-slide to function properly. This also helps with people like me where I like to use two fingers for stereo source faders, where I'd otherwise fight the second fader.

Using this option should help when a situation like this occurs so that one can finish the show without continuing issues with the faders.
 
Re: X32 Discussion

Can't say that I've had problems with the faders on my X32, but I don't use the matrices.

I do have a question about show files on USB sticks.
I used my X32 with a regular band, and I have a complex show file with FX routings, Ultranet, etc.
If I save that to a USB stick and load it in to another console, will EVERYTHING come across?

I'm gigging at a venue this weekend that has an installed X32. They don't have their Ultranet set up, but I have a Cat5 reel that I will run to the stage.
It's been a while since I've had a white glove gig, so I'm hoping that all settings are transferrable.

Does anyone have any experience of this?

Karl.

Everything but the global settings page transfers (the four link preferences and the lcr/lr-m selections of the page transfers, but not the rest) , but remember that the library files are not part of the show file, and these files have to be saved and loaded separately if you have special presets etc. that you want to carry with you.
 
Last edited: