ProSoundWeb Community

Sound Reinforcement - Forums for Live Sound Professionals - Your Displayed Name Must Be Your Real Full Name To Post In The Live Sound Forums => LAB: The Classic Live Audio Board => Topic started by: Tom Bourke on December 02, 2017, 10:25:54 am

Title: QL5 cue bus and mix bus crosstalk problem.
Post by: Tom Bourke on December 02, 2017, 10:25:54 am
Had an interesting problem yesterday.  QL5 doing a corporate band on in-ears.  They are running there own mixes on ears and are very low maintenance.   At some point I noticed that pressing cue button on any in or out also brought up vocals in the cue wedge.  Cue a CH with nothing plugged in and vocals would show up in the cue wedge?!?

End of show we started tracing down the problem by turning off sends to mixes one by one.  Turns out anything sent to mix bus 13 also showed up in the cue wedge.  Mix 13 was set as a verb send to an internal FX.  OMNI 13 was patched as the cue wedge.  Muting any sends would mute the cross talk.  However muting the mix bus 13 master did not mute the cross talk.  Console should be on the latest firmware and SOP is to initialize before any new setup.  No RIO or other Dante in use.  We checked the patch and any place we could think of.  Released cue and toggled cue follows last press.

We plan on contacting Yamaha but I was wondering if any one else had some thing like this happen.
Title: Re: QL5 cue bus and mix bus crosstalk problem.
Post by: John Roberts {JR} on December 02, 2017, 10:37:46 am
Had an interesting problem yesterday.  QL5 doing a corporate band on in-ears.  They are running there own mixes on ears and are very low maintenance.   At some point I noticed that pressing cue button on any in or out also brought up vocals in the cue wedge.  Cue a CH with nothing plugged in and vocals would show up in the cue wedge?!?

End of show we started tracing down the problem by turning off sends to mixes one by one.  Turns out anything sent to mix bus 13 also showed up in the cue wedge.  Mix 13 was set as a verb send to an internal FX.  OMNI 13 was patched as the cue wedge.  Muting any sends would mute the cross talk.  However muting the mix bus 13 master did not mute the cross talk.  Console should be on the latest firmware and SOP is to initialize before any new setup.  No RIO or other Dante in use.  We checked the patch and any place we could think of.  Released cue and toggled cue follows last press.

We plan on contacting Yamaha but I was wondering if any one else had some thing like this happen.
Sounds like two buses shorting... maybe a ribbon cable, or solder issue.

JR
Title: Re: QL5 cue bus and mix bus crosstalk problem.
Post by: Andrew Hollis on December 02, 2017, 10:57:10 am
Sounds like two buses shorting... maybe a ribbon cable, or solder issue.
This is not possible on a digital console. Digital data cannot be haphazardly multiplexed together with cables and solder.

Seems more operational. Post the file.
Title: Re: QL5 cue bus and mix bus crosstalk problem.
Post by: Tom Bourke on December 02, 2017, 11:08:03 am
This is not possible on a digital console. Digital data cannot be haphazardly multiplexed together with cables and solder.

Seems more operational. Post the file.
Here is the CLF file.  Plug a mic into ch15 and and powered monitor into omni 13(patched as cue L).  This file was taken after we had unhooked and started turning sends off.

I don't know if the headphone out is affected.  My co-worker will have more time today to test some stuff.
Title: Re: QL5 cue bus and mix bus crosstalk problem.
Post by: Tom Bourke on December 02, 2017, 04:17:01 pm
Update, the cross talk is present in the headphones as well. Even with the omni un-patched.

We have not done a power cycle or reset yet.  non band part of gig is still going.
Title: Re: QL5 cue bus and mix bus crosstalk problem.
Post by: Tom Bourke on December 03, 2017, 12:35:26 pm
Gig was over today and my co-worker did a power cycle and the problem cleared it self.

We were playing with the monitor and cue settings a few hours before the band so maybe we found one of those bugs that takes 20 random button pushes to recreate and no one ever does that sequence.  I assume the power cycle reloads the user preferences and so routing gets set to match the gui again.