X32 Discussion

Re: Routing question

I have a routing question for using two consoles. The 'why' is probably too long and would just confuse the question (as if the question probably won't get confused in the first place! ;) ).....

I have a baseline configuration for FOH/MON setup via AES50 which has the XLR outs of the MON console set as *13,*14*,*15, *16 (AES50 A). So the FOH outputs are physically at 13, 14, 15, and 16 outputs on the MON console. All of this works fine.

The other day I had a need for 2 consoles on two stages where essentially it would work like that mon/foh setup BUT ALSO needed the two consoles to send a feed to each other's outputs (the two stages weren't live at the same time but would alternate).

I could physically do feeds via balanced lines but I was curious if it could be done via AES50 and I never could get that to work. I don't know if it's just not physically possible, or if I did something wrong in the two ways I tried.

In one way Console A was setup with XLR outputs *13,*14*,*15, *16 (AES50 A) while console B was setup with *9,*10*,*11, *12 (AES50 A).
Then console A had mixbus 11 assigned to both output *15 as well as output 11.
Then console B had mixbus 11 assigned to both output *11 as well as output 15.

The idea being when stage A was live it would feed a fill mix to local output 11 and then send that same mix to output from console B out of output 11 on the B console via AES50.
Then when stage B was live that console would feed a fill mix from local output 15 as well as send via AES50 a signal to output from output 15 of console A.

I also tried a couple variants of that (including splitting outputs).

I could always send to the mains just fine, but I could never get the the feeds going both ways for the fills that were needed. I did get it to work one way and not the other.

Probably a better way to explain the concept to something a bit more normal with only a slight twist would be to imagine you had a FOH/MON setup going with AES50. The mon console is not physically connected to XLR outputs 13-16 (so you see asterisks in the routing page) so that FOH outputs feed the mains thru the mon console. Now, for whatever reason, you have a powered speaker at FOH that the mon engineer wants to send a singal to you to output from the FOH console... sent from the mon console. So then, how would you do that? Can you do that?

What it ultimately seemed to me like was I couldn't have both consoles functioning with a set of outputs not physically on the console (even though they were a different set of outputs on each console). It acted like only one console would allow for that. But if that is the case, how was it that it was always the 13, 14, 15, 16 outputs that worked properly rather than the consoles just getting confused? Which leads me to think maybe I missed something....
Hi Alan,

I, too, am not quite sure what you are asking for, but what I keep thinking of is the "blocks of 8" routing limitation. It seems to me that if you had one console coming off of the other's 1-8 and the reverse using 9-16 you can get what I think you might want. Assuming you only have one Ethercon cable running between consoles. If you had two then I think you could use 9-16 consistently.

You can also set up a scene with the routing you want for each console and then load the scene when the console changes. I'm still not hip to snippets, but I bet that's a more elegant way to do it than scenes.

This is the kind of thing I have to set up and try to really comprehend what's going on (or not going to go on). Hope I haven't muddied the waters.

Please report back with what you find.
 
Re: Dante

I made the jump and ordered AKG DMS800 series wireless. These come standard with a dante interface.

I do mainly use my X32 rack with a laptop connected to USB for multitracking, and would love to add a second laptop for backup.
Say I order the X32 dante interface, can I connect all (2 channels wireless, multitrack laptop 1, backup multitrack laptop 2) to the X32?
Do I need to pay for (dante) licenses or whatever to get it working?

I understand that the maximum I can get into the X32 is 32 channels, but is it easy to swap output channels from 1 laptop to the other?
Dante is point-to-multipoint so one source can feed several recievers.

All routing is done using audinte's dante control program. You can actually create and save routing configurations in that application so it is fairly easy to use. It is easy to mis-route stuff if you are not carefull as the dante matix can become quite big and you don't see the whole matix on one screen. Other than that it is quite easy to use.

If you use dante enabled mics then you don't need to route them from your x32, but you can route the mics directly to your recording computers as well.

You need to buy two virtual soundcards (DVS) at $30 each, but other than that... Also, look into dante-via. This cool audinate software let you use a normal conputer as a dante device where your applications becomes virtual soundcards on the dante network. Really cool if you are into skype and things like that. You also get to have each application on separate faders if you want to as well...
 
Re: Routing question

Hi Alan,

I, too, am not quite sure what you are asking for, but what I keep thinking of is the "blocks of 8" routing limitation. It seems to me that if you had one console coming off of the other's 1-8 and the reverse using 9-16 you can get what I think you might want. Assuming you only have one Ethercon cable running between consoles. If you had two then I think you could use 9-16 consistently.

You can also set up a scene with the routing you want for each console and then load the scene when the console changes. I'm still not hip to snippets, but I bet that's a more elegant way to do it than scenes.

This is the kind of thing I have to set up and try to really comprehend what's going on (or not going to go on). Hope I haven't muddied the waters.

Please report back with what you find.

Yes, I am going to have to set this up in the shop with the consoles side by side.
But as for the blocks of 8 limitation... Doesn't the XLR Out page get us around that and give us blocks of 4?
In the MON/FOH setup configuration that I've used several times, only XLR 13, 14, 15 and 16 are physically unassigned from the Mon console and those outs are then fed via AES50 from the FOH console (L-R, Fill, Sub) 13-16. Meanwhile, the mon console has 12 outputs on it for mixes.

Although maybe bubbling under the surface, the block of 8 can't be bidirectional (so to speak) and maybe if I would've assigned 5-8 to AES50A on the XLR out page of the other console (thereby using a different 4 from that initial group of 8 (9-16)) then maybe it would've worked..... ?

A scene or snippet wasn't going to get me what I needed until I had the initial idea sorted because certain parts of the routing that was working as expected, needed to remain constant. If I could've gotten things working in some fashion, a snippet or scene then might've helped make things a little more elegant/efficient.

As I said in the other post, the best way to think of this would be a MON and FOH console scenario connected via AES50. FOH amps are fed from Mon console outputs via AES50 rather than copper drivelines from the FOH console. Normal stuff at this point.
Then, the mon engineer wanting to send a mix to output from the FOH console via an XLR output (on FOH console) to a powered speaker (for whatever reason).

That would be the same concept as far as routing goes as what we were needing to happen with fills.
 
Re: Routing question

This may be buried somewhere in the 552 pages of post but has anything been done to resolve :
1: The flashing mutes on ipad when on sends on fader.
2: The slowness of the latest ipad application to respond to context changes.
3: (now this is a really odd one) Spontaneous assisnment of Ch5 & 6 to DCA1 when nobody asked for this to happen.
(this happened to me and I thought it must have been finger problems, then it happened to another operator, which is when I got suspicious).
M
 
Re: Routing question

1. Either wait for another update or use the Android app (which is better anyway)
2. See 1. above.
3. I don't recall seeing that one cropping up here before and haven't experienced it myself. Presumably it's a random occurrence so not possible to recreate on demand?
 
Re: Routing question

Yes, I am going to have to set this up in the shop with the consoles side by side.
But as for the blocks of 8 limitation... Doesn't the XLR Out page get us around that and give us blocks of 4?
In the MON/FOH setup configuration that I've used several times, only XLR 13, 14, 15 and 16 are physically unassigned from the Mon console and those outs are then fed via AES50 from the FOH console (L-R, Fill, Sub) 13-16. Meanwhile, the mon console has 12 outputs on it for mixes.

Although maybe bubbling under the surface, the block of 8 can't be bidirectional (so to speak) and maybe if I would've assigned 5-8 to AES50A on the XLR out page of the other console (thereby using a different 4 from that initial group of 8 (9-16)) then maybe it would've worked..... ?

A scene or snippet wasn't going to get me what I needed until I had the initial idea sorted because certain parts of the routing that was working as expected, needed to remain constant. If I could've gotten things working in some fashion, a snippet or scene then might've helped make things a little more elegant/efficient.

As I said in the other post, the best way to think of this would be a MON and FOH console scenario connected via AES50. FOH amps are fed from Mon console outputs via AES50 rather than copper drivelines from the FOH console. Normal stuff at this point.
Then, the mon engineer wanting to send a mix to output from the FOH console via an XLR output (on FOH console) to a powered speaker (for whatever reason).

That would be the same concept as far as routing goes as what we were needing to happen with fills.
OK, Alan, I got some time today and set up a couple of consoles and got what you want, I think.

The block of 8 thing is relevant on the AES50 bus. Let's see if I can describe the setup:

"Mon" console has XLR inputs for both consoles, XLR outputs 1-8 for itself, 9-16 from FOH console on AES50A-9-16. This console has the internal console sync. AES50A outputs 17-24 set to Out 1-8.

"FOH" console has AES50A outputs 9-16 set to Out 9-16. XLR outputs 1-4 set to AES50A 17-20, since in my case I was driving one monitor mix from the Mon console output 1, and was trying to send mon mix bus 2 to the FOH monitor. If you want mix 5-8 to go there, you'd set it to AES50A 21-24.

Now the FOH mon was coming out of FOH console mix bus/XLR 2 with a mix from mix bus 2 on the Mon console.

Was that what you wanted?

Don't ask me why setting the Mon console AES50 outputs 1-8 to Out 1-8 didn't result in the mix coming through at FOH. If it were my problem I'd screw around with it some more, but I got it to work and took it apart and am done. I'll concede I might have done something wrong to make this setup not work and the other one work.

And maybe your 12 monitor mixes is relevant. I don't know if you can get a 13th mix (the FOH monitor) out of your console. I forgot about your 12 mixes, sorry.

Your turn to fool around with it and report back.

HTH.
 
Re: Routing question

Thanks Dan. The 12 mixes are not really a factor overall... I only needed 6 when it was all said and done. I will copy and print what you did and see how it works when I get around to trying this setup in the shop. Haven't tried it yet and have a couple of ideas of my own to check too.
 
Re: Routing question

Hai all! Sorry if i hijack your post but i just want t update my progress. X32 successfully upgrade to new software. I happened to meet x32 owner also using s16 with UTP cat5e foe pass 3 years with no issue. Our Cat 7 arrived but it wont work. So custom make a UTP brand Xindak. Hope no pop any more. Thanks
 
Cable

Hai all! Sorry if i hijack your post but i just want t update my progress. X32 successfully upgrade to new software. I happened to meet x32 owner also using s16 with UTP cat5e foe pass 3 years with no issue. Our Cat 7 arrived but it wont work. So custom make a UTP brand Xindak. Hope no pop any more. Thanks

I just saw this post.

I'm not sure why Cat7 didn't work?

BUT.... You should've used STP cable on the one you made. It's well documented that using unshielded cable is just asking for trouble. Of course it works, until it doesn't. It might work years for you without a pop. Or it might work a few minutes. Either way, it's just a question of time.
 
Re: Cable

I just saw this post.

I'm not sure why Cat7 didn't work?

BUT.... You should've used STP cable on the one you made. It's well documented that using unshielded cable is just asking for trouble. Of course it works, until it doesn't. It might work years for you without a pop. Or it might work a few minutes. Either way, it's just a question of time.
Also curious why CAT7 didn't work.

Regarding the STP vs. UTP, given how strongly STP has been advocated here, I don't think it's worthwhile to discuss it with anyone who has been warned and still decides to use UTP.

I look forward to reading complaints of problems resulting from that decision and consciously ignoring them.
 
Re: Cable

Also curious why CAT7 didn't work.

Bit of a stab in the dark here. When used for Ethernet, CAT7 is better than CAT6 which is better than CAT5. Dead simple. However, AES50 isn't Ethernet. The way it uses each twisted pair isn't the same as Ethernet. AES50 uses separate pairs for clock and for data. The twist length (which affects capacitance and overall length) isn't the same for each individual pair within the overall cable and also varies between each CAT standard. I don't have any CAT7 in front of me but having just compared some CAT5 and CAT6 side by side, the twist length is much shorter in the 6 and differences between pairs looks more pronounced. My hunch would be that CAT7 is just too far off the CAT5 spec that AES50 was designed to work with. As per all other other advice - use the right cable and it'll just work.
 
Re: Cable

UTP solid will work fine, unless there is any chance of a static discharge.

Stranded wire works fine, unless the cable gets moved around a bit during use, that can cause dropouts, I've experenced that first hand.

STP cable works well to protect against static discharges that interupt signal/cause pops , but FTP cable also works just as well that I find personally..

Metal RJ-45s with drain wire soldered at both ends and ethercons are needed to prevent static discarge problems.

Cat-5 works well, Cat-6 is quite stiff but takes a beating better and is a little less likely to short out as bad when it's run over by a 400 pound staging cart...
 
Re: Cable

UTP solid will work fine, unless there is any chance of a static discharge.

And that's the crux of the matter, isn't it?

Stranded wire works fine, unless the cable gets moved around a bit during use, that can cause dropouts, I've experenced that first hand.

Could you please talk about that a little bit? How long was your cable, how much movement, was the movement in the middle or at the ends, any speculation about what aspect of the stranded caused the dropouts, etc.?

I have two cables made with stranded, one is 150' long and is the one I use most, the other is 250' long and gets used once a year.

The shorter one has never had any problems. It gets walked on during shows to varying degrees, and I've never heard a blip out of it that wasn't supposed to be there.

I'm mostly not present when the longer one gets used and I got a report that there was a disruption once when somebody walked on it. We can easily make it so people can't walk on it, so no problem, but still. I haven't been able to intentionally cause a disruption with the current iteration of the cable, although the disruption in an earlier iteration was what caused me to do the Audio Over Ethernet Cable workshop for my local AES Section a few years ago. I feel silly posting the URL here over and over but I wouldn't be surprised if there are people who haven't heard of it, so

http://www.aes-media.org/sections/pnw/pnwrecaps/2013/jun_cat5/

Please share your experiences as your comment is the first I've heard specifically targeting stranded along with a specific symptom.

Thanks,
Dan
 
Re: Cable

UTP solid will work fine, unless there is any chance of a static discharge.

Stranded wire works fine, unless the cable gets moved around a bit during use, that can cause dropouts, I've experenced that first hand.

STP cable works well to protect against static discharges that interupt signal/cause pops , but FTP cable also works just as well that I find personally..

Metal RJ-45s with drain wire soldered at both ends and ethercons are needed to prevent static discarge problems.

Cat-5 works well, Cat-6 is quite stiff but takes a beating better and is a little less likely to short out as bad when it's run over by a 400 pound staging cart...

I was messing with UTP earlier, one solution that may help is to power the stage box from the same power strip (same UPS in my case) via grounded extension cord. It sounds kinda stupid to run extension cord that long but it provides a solid ground connection between the mixer and the stage box, thus eliminating static discharge. Not 100% guaranteed, but in some situations may help. Building electrical ground may be bad (even though your pocket tester shows that the power outlet is grounded). Don't assume that building ground is solid all the way, I've seen a sloppy electrical work more than a few times. BUt of course using STP, even generic ones, is preferred.
 
Re: Cable

With UTP static charge occurs whether one or both sides is grounded on whatever way... What you eliminate is that the common mode voltages get really high... But I doubt that it does much except a little charging of the cable...

Pulling UTP over a carpet floor will charge a lot.
 
Re: Cable

I was messing with UTP earlier, one solution that may help is to power the stage box from the same power strip (same UPS in my case) via grounded extension cord. It sounds kinda stupid to run extension cord that long but it provides a solid ground connection between the mixer and the stage box, thus eliminating static discharge.
Unfortunately, this isn't true at all. The static discharge is not between the stage box and the console it's between a person's finger or whatever and the console or a microphone or the stage box, after the person has shuffled across a carpet or whatever.

To test this I've followed Brian Wynn's example and used a modified BBQ sparker to generate a reliable spark (static equivalent). You can do it, too, for less than $20.

Spark + console + UTP + stage box = bad.

Repeatedly.

Guaranteed, probably around 6 or 8 times out of 10. However, once a disruption has occurred the threshold for further disruptions seems to be reduced for sparks soon after the first disruption, so the odds increase. Or at least that's how it seemed.
 
Re: Cable

The Stranded cable (250') that I have is FTP with metal rj45 ends soldered to drain wire with ethercons. I've heard it drop out in summer when flipping the cable mid span over chairs. I've heard it drop out quick (no pop, just a 1-2 second drop out) when stepped on very randomly, doubt it was static, heard it on shows in summer/early fall. I have heard the same drops on UTP cable from static like everyone else, FTP shield with metal ends, soldered drains, ethercons and that problem gone. Seems to me that the AES50 system used on these consoles is not as tolerant/forgiving as the Roland digital snake I used to use all the time... I never heard that thing drop out, even with UTP cable, except the one time when a 400lb staging cart ran right over that cable the signal went dead, no pop at all. A quick little cable message, unplug/replug and I was up and going again. Guessing the issue with the stranded might be the spacing relationship between the pairs changing, total guess though...
 
Re: Cable

The Stranded cable (250') that I have is FTP with metal rj45 ends soldered to drain wire with ethercons. I've heard it drop out in summer when flipping the cable mid span over chairs. I've heard it drop out quick (no pop, just a 1-2 second drop out) when stepped on very randomly, doubt it was static, heard it on shows in summer/early fall. I have heard the same drops on UTP cable from static like everyone else, FTP shield with metal ends, soldered drains, ethercons and that problem gone. Seems to me that the AES50 system used on these consoles is not as tolerant/forgiving as the Roland digital snake I used to use all the time... I never heard that thing drop out, even with UTP cable, except the one time when a 400lb staging cart ran right over that cable the signal went dead, no pop at all. A quick little cable message, unplug/replug and I was up and going again. Guessing the issue with the stranded might be the spacing relationship between the pairs changing, total guess though...
Thanks for this!

Is your cable CAT5e or CAT 6?
 
Re: Cable

Cat5e FTP.
That fits in with my theory of why CAT6 is better for our purposes than CAT5e.

I think the problem that I had (resulting in the workshop and videos) with the sync being lost due to cable movement is caused by the pairs' capacitance changing by some combination of movement relative to each other. Pulling and squeezing in my case, flipping around in a big way in yours.

CAT5e may or may not have some kind of filler inside the cable to isolate the pairs, and most often does not so that the four pairs are in direct contact with each other. Differential movement between touching pairs changes the capacitance.

CAT6 seems to alway have a longitudinal spacer to keep the pair apart in order to meet spec. The spacer is in some form of X, in which there's a pair in each valley of the X so they are farther apart. Sometimes the spacer is like an HH with no gap between the H's, or maybe some other shape. That runs the whole length of the cable so the pairs are always apart.

I recall times when I was flipping around an analog snake with the PA on and hearing microphonic type sound out of the speakers, so analog is not problem-free, either, although that's better than white noise, maybe.

BTW, I was on a panel at the last AES convention describing my experiences and the guy next to me said that the white noise was a symptom of AES50 losing sync. FWIW.

Thanks for confirming my suspicion. No guarantees, but my hope is that you wouldn't have had that problem with CAT6.

FTP is Foil Twisted Pair? Hadn't heard that before.

Googling finds a document I hadn't seen before that indicates that STP really doesn't have a precise meaning. Interesting. Thanks for bringing that to my attention. How much I don't know.....

http://www.belden.com/blog/datacenters/STP-UTP-FTP-Cable-More-7-Types-When-to-Use-Them.cfm