Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; view has a deprecated constructor in /home2/edit/public_html/sites/all/modules/views/includes/view.inc on line 19

Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; views_display has a deprecated constructor in /home2/edit/public_html/sites/all/modules/views/includes/view.inc on line 1910

Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; views_many_to_one_helper has a deprecated constructor in /home2/edit/public_html/sites/all/modules/views/includes/handlers.inc on line 616
M/E lockouts in MP2 | Editsuite.com

Hello Editsuite.com friends,

Due to tons of abuse, we now require that you request user access by sending us your Login, Name, Email Address, Phone Number, and Profession by submitting that info HERE.  I'll review your request and try to get back to you within the week.  You can't imagine how many folk want to trash forums with bogas advertising. 

Also, please help us gain enough Facebook "Likes" to have a custom Facebook URL!  

--Gary Lieberman

M/E lockouts in MP2

3 replies [Last post]
SQuinn
User offline. Last seen 2 years 22 weeks ago. Offline
Joined: 31 Aug 2010

We've been having an odd intermittent issue while in Multi Program 2 on our 8000.

Punching most of the show in M/E3. I can have M/E1 or 2 on the A bus, punch off to any other source, but then -at completely random times- the board will not allow either M/E1 or 2 to go back into either the A or B bus on M/E3. Keep in mind, when this is happening, nothing else is being recalled or fired off. I -can- punch up the locked out M/Es on P/P when 3 goes wonky.

This happens once every couple weeks or so, with no warning and the only way to clear it up is to take M/E3 back to Standard Config and then back into MP2. No matter what we do, we cannot recreate it the problem, even down to the exact keypresses.

Has anyone else seen it, or have a theory? I suspect a bad card on M/E3.

Bill Mastorakis
User offline. Last seen 9 years 16 weeks ago. Offline
Joined: 29 Apr 2006

I just dealt with this issue myself. It was locking out aux busses as well.

What it ended up being was a PGM/PST timeline had Util paths off. I was using the Util buses as a contributing source to program. As has been experienced in the past, despite being OFF, the timeline would occasionally call up a cross point, causing a re-entry that the switcher didn't like (in this case-PGM)

I had to recall each effect, turn on the path for the Util busses, MOD all, reset the Util busses to where they needed to be (something other than PGM), mod all again, turn paths off for the Util busses and mod all again.

Be advised, one of the software revs released in the last year or so has reduced the size of timing window the switcher will accept on re-entries. 

 

Bob Ennis
User offline. Last seen 4 years 35 weeks ago. Offline
Joined: 24 Aug 2005

The only time I have seen this is when one of your other M/E's is looking back on one of its buses at the 1st M/E...thus taking one of these M/E's could cause feedback.  Check your 3 Utility Bus feeds to see if they're looking at M/E 3 or if M/E 3 is looking at one of the other M/E's somewhere on the keyer or Utility buseswhich could also cause feedback.  Or try turning on the MPII Free Re-entry, which allows you to go into feedback if you wish.  If you turn on FR and you can re-enter the M/E's then it's a matter of you having M/E 3 somewhere on those other M/E's; if FR is on & you still can't take the M/E in question, then I would agree that it could be a bad board.

Bob Ennis

SQuinn
User offline. Last seen 2 years 22 weeks ago. Offline
Joined: 31 Aug 2010

Thanks, Bob. We run the board with MPII free reentry toggled on. It happens so randomly (we're not seeing any looping) that it gets maddening to track down. I think it may be a slow failure.