Mutes not operating properly

[Keithws]

We are having an intermittent issue where we may mute or unmute a channel and it will show that has taken place on 2 remote computers we have but the host computer is opposite of what it should be so basically the channel is not umuting. Has anybody else had this issue or does anybody have any ideas of things we can try to fix this issue. We are using 2.9 at the host and at both remotes.

Thanks.

[Bob L]

This has been reported when using midi controllers... but not when operating with the mouse.

Are you using a controller?

Bob L

[hclague]

This has been reported before. You can do a search. I assume that this happens only when trying to mute/unmute using the buttons on a midi controller ( i.e. BCF2000, Mackie etc...). That's the case for me anyway. I can never get it to occur if I'm clicking the button on the screen. It seems to have something to do with midi?

Hal

Oops Bob beat me to it.

[Keithws]

We are using the behringer controllers and suspected midi but as I said it shows properly on 2 different remote computers just not the host. I would think if it was a midi issue that it wouldn't indicate properly on the remotes.

[Bob L]

It would seem so... but this has been an elusive issue... most can not duplicate it even though they have had the issue.

I can not duplicate it here yet at all... that is the problem... very hard to modify and fix the code if I can't tell that I fixed it.

Can you give me a step by step way to cause this to happen repeatedly... perhaps you can deliver the elusive clue to chasing down the problem.

Bob L

[JLepore]

Just to clarify .. where is the controller that was used to change the mutes in this case? Was it on one of the remotes or on the host.
Did both remotes get updated and just not the host?

Somehow that would indicate the message got in from the controller if it was able to keep two network machines in sync.

[Keithws]

It is a behringer remote that is attached to a remote computer. I wish I could give you a step by step process to duplicate it. It is very intermittent. Yesterday when we were testing it, I got it to happen several times, it took just muting and unmuting a channel repeatedly until it happened. If I did notice anything, I was able to make it happen more often when multiple actions such as fader movement was happening at the exact same time. Also to clarify it is not only a mute situation but we have also seen where it it says it is muted on the remote station but the channel is is actually not muted.
I really appreciate your quick response to this thread Bob and we have been really pleased with the console overall.

Keith

[Donnie Frank]

It would seem so... but this has been an elusive issue... most can not duplicate it even though they have had the issue.

I can not duplicate it here yet at all... that is the problem... very hard to modify and fix the code if I can't tell that I fixed it.

Can you give me a step by step way to cause this to happen repeatedly... perhaps you can deliver the elusive clue to chasing down the problem.

Bob L

I have occasionally had this issue. Here are the consistencies:

1) Always on a remote computer (wireless).
2) Always on a BCF-2000 via USB interface.
3) And (I believe) fixable by bouncing around F-Keys (redraws???).

I believe it was most prevalent when I jumped the Behringer over to the next 8 channel bank (P-2) for the first time during a show. That would make things "weird" in that the BCF faders wouldn't snap to match the virtual console. They would just sit there. Moving the faders would wreak havoc, as the virtual fader would snap to match the BCF fader location. e.g. If the virtual console reflected -40dB on channel one, but the BCF channel 1 was on 0dB from the previous console, touching the BCF fader would make the virtual channel snap up to +0dB. To avoid the "havoc" all I would have to do is F-Key to another scene and then back and then the faders would snap into place. The only way I could reproduce it was if I lost my WiFi connection or closed the remote session and opened it back up.

To clarify, here's the order of what I did:

1) Set SAC to FOH console.
2) F-Key to a monitor console.
3) Advance the BCF channel focus from 1-8 (P-1) to 9-16 (P-2). BCF faders don't move.
4) F-Key back to FOH console (then BCF faders snap into place).
5) F-Key back to monitor console. BCF faders snap into place again.

This is going from memory while performing, so I wasn't exactly concentrating on SAC...just pushing faders. I've had other symptoms with the same exact rig:

The Behringer continued to mix perfectly (control audio), but changes were not reflected on the screen...which included faders, solo and mute buttons (fortunately the BCF buttons have LED's to reflect state). As a drummer this was a minor annoyance because I mix off the BCF exclusively. So I basically ignore the laptop while I'm performing. But I could see how this would be an issue as an audio engineer.

I put this off as a WiFi issue, as I don't have this problem when I use my Linksys WRT54g. This only occurs when I use the house router, which is a Belkin, I believe. I have never had any of these issues on the host.

My laptop is nothing special; a Dell 700m. I have used all 3 versions of SAC in this room; 2.7, 2.8 and 2.9. I don't recall having any issues with 2.9 SACRemote, but I will keep an eye on it next time I play that room.

I hope this helps. I'm curious to know if you can reproduce this. The deciding factor may be dubious WiFi connectivity or interference from other WiFi transmissions.

[Keithws]

We are not set up wirelessly, hard wired through router.

[JLepore]

And you say the screen on the other remote (the non-control surfaced one) updated to the correct state while the host showed the wrong state?

[Bob L]

If any screen updates it suggests that the signal came in from the controller... and if other remotes changed to follow, then that means the signal got to the host and was passed on from there... the remotes do not communicate between each other... so again... there still is no clear cut approach to finding a fix... since it seems so intermittent...

The trick is to figure out what is different during a show situation in your hookup that is not the same when you try to test at home and cannot get the problem to happen?

I really want to help and nail this one... but I just cannot seem to cause the problem no matter how hard or how fast I beat on the mutes... I have also tested on three different controllers... they all stay perfectly in sync with the screen and the action.

Bob L

[JLepore]

But the new clue in all of this is:

The controller transferred the data to the remote it was hooked to - thus eliminating the MIDI interface and MIDI template hooks.

The remote send the mute command properly to the host since it was reflected on the other host - eliminating the communication from the remote->host AND host->remote #2

Therefore the host is receiving and retransmitting the control change, but not acting upon the data itself. One would think that would be a much smaller code path to trace down now.

Since it seems to be acting exactly the same as experiences others are having both on the host and remotes with this, I would say this eliminates the MIDI red herring.

[hkmorgan87]

I too have had the same issue with my behringer controller. I've learned to hold the mute button for about a second. It almost seems like the controller gets bogged down.

Testing with midi ox. I was able to duplicate the issue. A quick tap of a mute or even solo button would not show up in midi ox. By holding down the button a little longer than a quicktap seems to correct the issue for me. I use a hard wired remote and the behringer is connected via USB.

[JLepore]

This also seems like the same behavior on the motormixes I've seen. Since the machine has to send MIDI commands back to change the state of the MUTE lights on the controller, it assures that the command MUST have been received by the host. It knew what the current state of the control was to be able to flip it and send the command to change the lights. Again, all it didn't do was update the host itself!

[Bob L]

Sounds good in theory... except... then how come MidiOx did not see his midi data?

And... I'm starting to think that perhaps the issue may be something like an echo in the host somehow that after the fact the mute is first correctly set in the remotes... then an echo toggles it back off again on the host... kind of like switch debouncing where a single push of a mechanical switch will actually toggle the switch a random number of times.

This sure would be easier if I could break this on one of my machines... then I could really dive down deep to breakdown exactly where the issue is.

Bob L

[JLepore]

You're talking about two different people with different issues. If you go back to the original poster's issues:

He certainly got the message from the controller
He sent the message to the host
The host resent the message out to the other remote
The host did not update itself.

If it received multiple messages, the secondary remote should have matched the host, seeing the multiple messages - it did not.

The second user not seeing the controller messages in midiOx is a different issue: In the first case, the controller obviously sent the message if you were able to send it over the network properly.

[Bob L]

I know... it does not make sense... the code updates the host first before ever sending the midi data back to light the controller or head out to the next remote... so none of it makes sense when looking at the code logic flow.

Its buried in there somewhere... could be a dual core issue with something spinning off to another cpu and executing out of sequence...

Those that are having the issue... do me a favor and try with the host set to one cpu... see if it still messes up.

Bob L

[JLepore]

Mine is and has been set as single core/rt priority

[Bob L]

Oh well... so the mystery continues.

Bob L

[hclague]

[quote=JLepore;175475]
The host resent the message out to the other remote
quote]

I don't believe the OP confirmed this statement. Did he?

My experience is similar to Donny's. This seems to have something to do with either how quickly one mutes and unmutes ( 2 pushes of the button ) on the controller, or perhaps the duration of how long the button is held? For me, this does not happen for just one single push.

Also on my system, when this happens, the host reflects the opposite state as the remote, thus indicating either the host did NOT receive the message or it received "Ghost" messsages as Bob suggested which left the host in the opposite state as the remote.

I do not usually have 2 remotes hooked up, so I cannot comment on that. Tonight i will have the opportunity to hook up 2 remotes so I will try and induce the problem and verify whats state the 2nd remote is reflecting.

Again forme, as others have also stated this never happens using the mouse to click the button on the remote screen.

Hal

[Paul Henry]

Could it be something as simple as a debouncing problem and "rapid fire" data being dropped or missed?

I actually have a similar problem with the mouse I'm using at work right now, it might have some corrosion or something on the contacts, but when I click it will sometimes send several very rapid clicks instead of just one, like it's making and breaking contact very rapidly.

Yeah, I need a new mouse.

[JLepore]

The host resent the message out to the other remote


I don't believe the OP confirmed this statement. Did he?


Yes, actually he said it in the very first post of the thread....


We are having an intermittent issue where we may mute or unmute a channel and it will show that has taken place on 2 remote computers we have but the host computer is opposite of what it should be ....

And he did verify that the controller was on one of the remotes...


It is a behringer remote that is attached to a remote computer.

Based on Bob's statement, the signal for the second remote could have only come from the host.


... and if other remotes changed to follow, then that means the signal got to the host and was passed on from there... the remotes do not communicate between each other...

[JLepore]

Could it be something as simple as a debouncing problem and "rapid fire" data being dropped or missed?

I actually have a similar problem with the mouse I'm using at work right now, it might have some corrosion or something on the contacts, but when I click it will sometimes send several very rapid clicks instead of just one, like it's making and breaking contact very rapidly.

Yeah, I need a new mouse.

If it was a debounce issue in this case, the second remote would match the host and be potentially different from the first remote (that had the controller attached to it). While I believe controllers can have debounce issues, that is not what seems to be happening with this particular problem.

[Keithws]

As JLepore is saying, both remotes are indicating the correct status, whether it's mute or unmute, the only thing not changing is the host, which leads me to believe that it is not a midi situation since both remotes receive the information and make the correct change, but the host does not. We too tried forcing it to single cpu and saw no change.

[Bob L]

Can you duplicate the problem with a list of repeatable steps?

Bob L

[Keithws]

The only way i can repeat it is to just sit and mute and then unmute a particular channel. I'm not changing screens or anything else. It is literally just mute, umute and it will eventually fail. Now one thing that we thought about over the weekend is that the channel we are changing is a DCA channel. I don't know if we mute/unmute an actual channel if the problem is happening because we do everything primarily from the DCA master section. I will try to play with it more today and see if the same problem occurs when we are actually muting/unmuting a channel itself.

[Bob L]

Well... this is the problem... I cannot change code and see if its fixed unless I can break it every time, then not break it after the code change... to say if I mute/unmute over and over and eventially it will break, gives nothing to go on... this is one of those elusive ?bugs? that continues to stay buried and well hidden.

I can mute and unmute hundreds of times... fast... slow... over and over... and it won't break for me... what is going on? :(

Bob L

[Brent Evans]

Could it possibly be something like hardware revisions?

Note... I'm not having the issue, but if it were something like this, it would be very elusive...

[JLepore]

I have had it do it on both single channels and Output (DCA) channels. I have also had it do it when many channels were selected in a temporary group (such as arm a group of channels to be ready to mute/unmute at start/end of set)

It doesn't appear to matter if only one channel has to be updated on the control surface or many.

[Keithws]

Here is the most recent findings. As we mentioned in an earlier post, our second remote was tracking properly when a change from the first remote was made. However today we are seeing just the opposite, in that the 2nd remote is showing opposite of the first remote occasionally. I say occasionally because we are seeing it is random on whether or not it follows the first remote, sometimes it does, other times it doesn't. Bob I'm beginning to believe that it is something possibly with the midi or our setup because you can't seem to reproduce the problem and also because of this. We are using 3 monitors on our system and the third monitor is being fed by a USB to Video adapter. We wondered if the USB bus was being bogged down at times and the Midi to USB wasn't getting the correct information all the time. So we unplugged the USB Video adapter and as of right now have not been able to reproduce our problem and the system works fine. However when I plug the USB to Video adapter back in, I can pretty quickly reproduce the problem. So we are going to try either installing a USB Card or if we can find one that will work in our computer, a second video card and see what happens.

[Bob L]

That's a possibly good find... although not yet conclusive... but sure makes sense... if the usb is getting clogged, then the midi data could be stomped on... I'll be anxious to hear more results of your testing.

Perhaps the RME cards that I use with their own hardware midi ports and drivers are why I cannot seem to duplicate the issue.

Bob L

[JLepore]

The only things on my USB busses are the MIDI interface and a mouse.

There are generally multiple USB controllers on any modern motherboard. Simply plugging devices into multiple controllers should eliminate any bandwith issues. I can certainly see video controllers over USB buss to be a bandwith hog. Somehow I doubt this has anything to do with why everyone else is having the same issue.

If you're not seeing it on your RME MIDI port, perhaps you should test on other MIDI interfaces. I don't recall seeing anywhere that RME cards are the only interface usable with SAC. Many of us are using MOTU which requires an external MIDI interface.

[Bob L]

My studio uses an old EMagic 8 chan midi box... I have the MotorMix hooked up there for demonstration purposes... can't make that break either.

Other than that... I have no other midi devices to test.

Bob L

[Paul Henry]

So let me ask the stupid question. How is MIDI data handled by the various busses and controllers involved in the MIDI signal chain, is it buffered and processed in sequence at every stage, or is it handled on the fly in realtime so that commands could potentially get skipped? And is it handled the same way by the USB bus as it is by the native MIDI connector?

[905shmick]

I've not experienced this problem, but I'm curious about one thing.

On the controllers that are showing different mute status than what is on SAC, if you bank switch to a different set of faders and then bank switch back, does the controller still show the incorrect data or does that clear it up?

[JLepore]

On the motormixes, it generally stays wrong. I believe I have fixed it once by changing to a totally different mixer, but generally the only way is to reload the MIDI template file - not something I like doing during a live show.

[Butch Bos]

The 4 or 5 times it has happened to me just changing mixers fixed it

Butch

[hkmorgan87]

What about drivers? Windows or controller specific? I personally have never been able to make bcf drivers stable enough to use. After installing the driver, the controller worked. After restarting, controller wouldn't work until the driver was reinstalled. So I stuck with the generic windows drivers.

Connection type, USB or midi cable? My bcf is hooked up via USB, and I also have a wireless mouse and keyboard. Maybe they are stepping on each other?

[Keithws]

We finally believe that we have solved our mute issue we were having. As mentioned in an earlier post, we were using a USB device that would allow us to feed video to a third monitor. We replaced that with a PCI video card and have had no more muting issues. Over the past weekend we had a show at our church which put the SAC to the test because it consisted of many mutes and unmutes taking place and it passed with flying colors. Thanks for everyones input.

[jlklein]

So, we know USB Video adapters cause issues...does anyone know if these Dell Display Port adapters to VGA and DVI cause any issues? I don't know what the protocol is they use, so I don't know if it's any different/CPU intensive than using the onboard VGA or DVI ports.

Thanks,
Jeff