Strange behavior on MIDI Ch. 3

R

RockDebris

Member
I have the MFC all set up for my admittedly, somewhat complex rig. This is just the MFC as a MIDI Controller, not with the AxeFX. Here are pertinent details of the issue:

I have an EVH 5150iii amp that comes equipped with a MIDI input. I have that set to RX on Channel 3 to switch the 3 EVH preamp channels using PC 0, 1 & 2.

I also have a MIDI Solutions Event Processor that, when it receives certain PC changes on Channel 16, will also send out commands to the 5150 on channel 3. (the reason for having this is that I have 2 amps, an ABY and a FootSwitch simulator all controlled via MIDI. The Event Processor adds an layer of abstraction to all of these devices for convenience .. I can just send a single PC change to the Event Processor if I want a particular amp on a particular channel and it takes care of setting all these devices).

If I send Ch 16, PC 1, this should normally switch the ABY to the 5150, activate the blue channel and simultaneously switch my second amp to its clean channel (to eliminate any hiss while I'm not using that amp). However, when sending that from the MFC, the 5150 goes to the blue channel for an instant and then switches to green. It's getting the command, but then it is being overridden. I've worked around this by ALSO sending the necessary command to Ch 3 from the MFC, then it stays blue. (normally, I would have MIDI Ch 3 set to OFF in the foot controller and just rely on the Ch 16 command). I have a successful workaround, but it is nagging at me.

What could be doing this override? I've stripped the MFC down so that no IA, Internal CC, XS or XP is doing anything I'm not aware of (I learned that the hard way when I was having a similar problem on Channel 1 where my ABY box is assigned. There was a CC command I didn't know about being sent from the depths of the MFC on Ch 1). Another possibility is perhaps the 5150 is responding to a secondary channel and it's not Channel 3 I should be concerned with, but even then I don't think I have the MFC (or any other device in my system) doing any extraneous commands. I try to run a pretty tight ship when it comes to sending MIDI I/O because of the complexity of my rig. Also, everything else is working perfectly controlled by the MFC and the Event Processor. For this one thing that is wrong, there are 100 things going right. I also know that the Event Processor programming is good, I've been using the Event Processor and the same programming in my rig for over a year, just with a different foot controller. Conceptually, all the same.

I guess I'm looking for any troubleshooting tips or something I haven't thought of. I can post the sys dump of my controller if it would help.
 
Last edited:
How exactly are you sending the PC1 on Ch16? Which switch? Or Which MFC-101 preset? What are the settings for the INT CC's for this preset? If you're using an external switch connected to the MFC-101 is it set to "Auto. Off" type? Check the PC on all 16 channels if you're using a preset selection to send the command. If you're using an IA Switch to send the PC then check also the CC0 and CC1 params for that IA Switch, and the Custom MIDI Message bytes (1 and 2) and check the "Length" parameter of each Custom MIDI Message to make sure that it is '0' - maybe some cruft in there. Those are just some thoughts off the top of my head.

... assuming of course that MFC-101 is the culprit ;-). You might want to make sure that "MIDI Rx PC" is turned off in the MFC-101 in case its getting some echoes and switching presets itself and then sending out commands associated with that new preset.
 
bwanagary said:
How exactly are you sending the PC1 on Ch16? Which switch? Or Which MFC-101 preset?
Click to expand...

Every Preset I program sends some PC on Ch16 via the preset PC programming options. That's the core of my amp switching/channel selection and it's always the first order of business. This is a full picture of what my presets are designed to do:

PC1: ABY box (always OFF because the Event Processor on channel 16 abstracts it)
PC2: FootSim box, for changing channels on Vox Night Train (always OFF because the Event Processor on channel 16 abstracts it)
PC3: EVH Channel Switching (should always be OFF, but had to program it due to stated problem.)
PC4: Strymon Mobius
PC5: Strymon Timeline
PC6: Strymon BigSky
PC7: Unused (OFF)
PC8: Unused (OFF)
PC9: Unused (OFF)
PC10: Unused (OFF)
PC11: Unused (OFF)
PC12: Unused (OFF)
PC13: Unused (OFF)
PC14: Disaster Area 8 signal looper (Usually OFF. There are presets in the device, but for now the IA switches and states handle everything)
PC15: Unused (OFF)
PC16: Event Processor. This hosts convenience programs that I wrote. The core reason for it is Amp/Channel Switching which happens all through Program Commands, but with less powerful foot controllers I have also programmed it to do a number of common tasks based on receiving CC messages (for instance, I can send CC#4 000/127 to bypass the Mobius ... lots of filtering stuff like that in there, all tied to receiving PC or CC on Ch16).

Then I have IAs. Unless noted, C2 and PC for each of these is OFF.

IA1: C1: BigSky Hold (momentary)
IA2: Unused (All OFF)
IA3: C1: BigSky Remote TAP (momentary)
IA4: C1: Timeline Remote TAP (momentary)
IA5: C1: Mobius Remote TAP (momentary)
IA6: C1: Disaster Area loop 4 (Toggle)
IA7: C1: Disaster Area loop 3 (Toggle)
IA8: C1: Disaster Area loop 2 (Toggle)
IA9: C1: Disaster Area loop 1 (Toggle)
IA10: C1: Mobius Bypass (Toggle)
IA11: C1: Disaster Area loop 8 (Toggle)
IA12: C1: Disaster Area loop 7 (Toggle)
IA13: C1: Disaster Area loop 6 (Toggle)
IA14: C1: Disaster Area loop 5 (Toggle)
IA15: C1: Timeline Bypass (Toggle)
IA16: C1: Timeline Remote TAP C2: Mobius Remote TAP (Toggle)
IA17: C1: BigSky Bypass (Toggle)

That is pretty much the entire system from the MFC perspective. I disabled all XS, XP and INT CCs as I haven't begun to use them. I ensure that they are all set to Chan 1 and then they are set OFF.

bwanagary said:
What are the settings for the INT CC's for this preset? If you're using an external switch connected to the MFC-101 is it set to "Auto. Off" type? Check the PC on all 16 channels if you're using a preset selection to send the command. If you're using an IA Switch to send the PC then check also the CC0 and CC1 params for that IA Switch, and the Custom MIDI Message bytes (1 and 2) and check the "Length" parameter of each Custom MIDI Message to make sure that it is '0' - maybe some cruft in there. Those are just some thoughts off the top of my head.

... assuming of course that MFC-101 is the culprit ;-). You might want to make sure that "MIDI Rx PC" is turned off in the MFC-101 in case its getting some echoes and switching presets itself and then sending out commands associated with that new preset.
Click to expand...

Thanks for the suggestions, I'll be going through it all with fine granularly again. I'll also make direct connections between fewer devices and narrow down what the minimum devices in the system are required for the problem to occur.
 
Last edited:
RockDebris said:
Every Preset I program sends some PC on Ch16 via the preset PC programming options. That's the core of my amp switching/channel selection and it's always the first order of business. This is a full picture of what my presets are designed to do:

PC1: ABY box (always OFF because the Event Processor on channel 16 abstracts it)
PC2: FootSim box, for changing channels on Vox Night Train (always OFF because the Event Processor on channel 16 abstracts it)
PC3: EVH Channel Switching (should always be OFF, but had to program it due to stated problem.)
PC4: Strymon Mobius
PC5: Strymon Timeline
PC6: Strymon BigSky
PC7: Unused (OFF)
PC8: Unused (OFF)
PC9: Unused (OFF)
PC10: Unused (OFF)
PC11: Unused (OFF)
PC12: Unused (OFF)
PC13: Unused (OFF)
PC14: Disaster Area 8 signal looper (Usually OFF. There are presets in the device, but for now the IA switches and states handle everything)
PC15: Unused (OFF)
PC16: Event Processor. This hosts convenience programs that I wrote. The core reason for it is Amp/Channel Switching which happens all through Program Commands, but with less powerful foot controllers I have also programmed it to do a number of common tasks based on receiving CC messages (for instance, I can send CC#4 000/127 to bypass the Mobius ... lots of filtering stuff like that in there, all tied to receiving PC or CC on Ch16).

Then I have IAs. Unless noted, C2 and PC for each of these is OFF.

IA1: C1: BigSky Hold (momentary)
IA2: Unused (All OFF)
IA3: C1: BigSky Remote TAP (momentary)
IA4: C1: Timeline Remote TAP (momentary)
IA5: C1: Mobius Remote TAP (momentary)
IA6: C1: Disaster Area loop 4 (Toggle)
IA7: C1: Disaster Area loop 3 (Toggle)
IA8: C1: Disaster Area loop 2 (Toggle)
IA9: C1: Disaster Area loop 1 (Toggle)
IA10: C1: Mobius Bypass (Toggle)
IA11: C1: Disaster Area loop 8 (Toggle)
IA12: C1: Disaster Area loop 7 (Toggle)
IA13: C1: Disaster Area loop 6 (Toggle)
IA14: C1: Disaster Area loop 5 (Toggle)
IA15: C1: Timeline Bypass (Toggle)
IA16: C1: Timeline Remote TAP C2: Mobius Remote TAP (Toggle)
IA17: C1: BigSky Bypass (Toggle)

That is pretty much the entire system from the MFC perspective. I disabled all XS, XP and INT CCs as I haven't begun to use them. I ensure that they are all set to Chan 1 and then they are set OFF.



Thanks for the suggestions, I'll be going through it all with fine granularly again. I'll also make direct connections between fewer devices and narrow down what the minimum devices in the system are required for the problem to occur.
Click to expand...

With the time you've taken to articulate your situation so well how could I not really make the effort to look at it? :). I'll check it out this weekend for sure.
Thanks for all the detail
 
bwanagary said:
With the time you've taken to articulate your situation so well how could I not really make the effort to look at it? :). I'll check it out this weekend for sure.
Thanks for all the detail
Click to expand...

I did a lot more troubleshooting on this and I've tracked the problem down to some kind of interaction between the Strymon BigSky, MFC and EventProcessor. I have no idea why yet, but the BigSky is the critical piece of the puzzle. If I take the BigSky out of any of the test configurations I've made, there is no problem. If I replace it with the Strymon Timeline or Mobius, there is no problem. My next order of business is checking BigSky firmware updates.

But there is more. I can reproduce the problem with the MFC, EventProc and BigSky. However, if I switch out the MFC for my old controller, there also is no problem. So that led me to think what is the difference between my old controller and the MFC, and the biggest difference is IA switches and controlling the 8 input looper. With my old controller I don't have IA switches, so within my looper I made presets and I just call the preset I need. With the MFC, no longer have to do that because I have the IA switches programmed to do the task. Next thing I tried was going into the MFC and turning OFF all "Send with Preset" option on the IA switches. Bam. That worked. So I started adding them back in one by one and what I found out was it didn't matter which ones were being sent or which state they were in, it was just the number of them being sent. Up to 4 the problem isn't present. Add a 5th and the problem is back.

So, I know a lot more today than I did yesterday, but I don't have a real explanation. All I know is that if I take the BigSky out, or replace it with another Strymon unit, the problem goes away. In the absence of a logical explanation, I suspect the BigSky is doing something beyond my ability to control. The other possibility is that the problem is really in the latest firmware updates of all Strymon pedals and if I update the other 2 units they may inherit the problem.

Any other ideas to test? Does this situation sound like any other you've heard?
 
I'll look in more detail later, but I bet it's still something to do with the Preset menu in the MFC, that thread of mine Yek linked to. (I know you checked it.)
 
Chris@KatsuKuriMedia said:
I'll look in more detail later, but I bet it's still something to do with the Preset menu in the MFC, that thread of mine Yek linked to. (I know you checked it.)
Click to expand...

Thanks. I tend to think at this point the MFC is doing exactly what I've asked it to do and that it isn't the culprit, but I welcome the opportunity to be proven wrong because that means I can fix my problem. I may post my system file later today.

I'm beginning to think that the reason this only effects the EVH (Channel 3) is because the EVH is the only device after the BigSky in the MIDI chain. If the BigSky were placed earlier, I wonder if I'd be reporting even more problems. I just thought of that and it sounds like something I need to test.
 
RockDebris said:
Thanks. I tend to think at this point the MFC is doing exactly what I've asked it to do and that it isn't the culprit, but I welcome the opportunity to be proven wrong because that means I can fix my problem. I may post my system file later today.

I'm beginning to think that the reason this only effects the EVH (Channel 3) is because the EVH is the only device after the BigSky in the MIDI chain. If the BigSky were placed earlier, I wonder if I'd be reporting even more problems. I just thought of that and it sounds like something I need to test.
Click to expand...

Great debugging job! If you post your sysex dump I'll take a look at it to see if anything jumps out at me. I have to say that the first thing that came to mind is that the MFC is sending too many commands too quickly for the BigSky to process properly.
-G
 
Last edited:
bwanagary said:
Great debugging job! If you post your sysex dump I'll take a look at it to see if anything jumps out at me.
-G
Click to expand...

Here is my MFC so far. Preset 005 ("Rhtm2") is one of the presets where I had to hard-code Ch3. If I were to turn Ch3 OFF, the problem begins and the same command that is being sent through my Event Processor on Ch16 is overridden somehow:

http://www.rockdebris.com/rockdebrismfc.zip

There is one thing I haven't mentioned that adds to the mystery. If I set Ch3 OFF to reproduce the problem, every now and then it works. Like less than 10% of the time. Also, if I switch to the ALT preset while on #5 (which is preset #10) and back again, it works every time. I get the Blue channel on the EVH as I would expect.

Thank you (and Chris) for taking any time you have to investigate.

Regards,

Joe
 
I have to say that I'm baffled so far, but thanks for the sysex - I'll see what I can find.
And you're welcome.

Here's a summary look at your IA switches - just confirm for yourself that its what you expect.
-G
IASwitches Screen
 
Last edited:
It might be of interest for someone to know WHY I use the Event Processor to control Ch 1, 2 & 3 in an abstract fashion instead of just hard-coding the values in the MFC. It is because I can go through different amps at different shows and I can replace the programs in the Event Processor so it controls different amps and devices without having to reprogram the presets in the Foot Control. If you are an object oriented programmer, you'll understand it is reducing hard-coded dependencies. It's like the Foot Controller has an Interface :)ICanSwitchAmpsAndChannels) and the Event Processor is implementing that Interface to provide control to any Amps, AB boxes and FootSims. :ugeek

I mean ... Rock and Roll! :evil

Seriously though, it works really great and reduces my dependency on having to always have an EVH 5150iii 50 Watt and Vox Night Train 50 Watt (or even have two amps .. I can reprogram the Event Processor for one amp operation in a pinch ... or it could 4 amps as long as I have enough MIDI controlled ABY boxes and FootSims ... sky is the limit.). This is where somebody will probably say I should just have an AxeFX. (yeah, yeah.)
 
Last edited:
bwanagary said:
I have to say that the first thing that came to mind is that the MFC is sending too many commands too quickly for the BigSky to process properly.
-G
Click to expand...

Yes, it seems like that, but then there are doubts based on the workaround, which is actually just sending 1 more command (the hard-coded Ch3 command). UNLESS, the act of sending this command interrupts the stream somehow so that by the time Ch16's command fires the BigSky is in an OK state. That would mean a race condition. Man, I hope it is not a race condition, but that would also explain why it works maybe 1 out of 10 times.

It's like a convoluted JFK conspiracy. If you believe there was more than 1 shooter (and "they" covered that up to make it look like a lone gunman) AND you believe a "pristine" bullet was planted to be found, then how can one reconcile that the conspirators were actually adding bullets to the investigation? The presence of even one more bullet would defeat the idea that there was only 1 shooter. HAHA. Sorry. I'm cracking up. Been staring at MIDI commands and menus too long this week.
 
Last edited:
RockDebris said:
Yes, it seems like that, but then there are doubts based on the workaround, which is actually just sending 1 more command (the hard-coded Ch3 command). UNLESS, the act of sending this command interrupts the stream somehow so that by the time Ch16's command fires the BigSky is in an OK state. That would mean a race condition. Man, I hope it is not a race condition, but that would also explain why it works maybe 1 out of 10 times.

It's like a convoluted JFK conspiracy. If you believe there was more than 1 shooter (and "they" covered that up to make it look like a lone gunman) AND you believe a "pristine" bullet was planted to be found, then how can one reconcile that the conspirators were actually adding bullets to the investigation? The presence of even one more bullet would defeat the idea that there was only 1 shooter. HAHA. Sorry. I'm cracking up. Been staring at MIDI commands and menus too long this week.
Click to expand...

lol. Dude - you need help! :)
 
bwanagary said:
I have to say that I'm baffled so far, but thanks for the sysex - I'll see what I can find.
And you're welcome.

Here's a summary look at your IA switches - just confirm for yourself that its what you expect.
-G
IASwitches Screen
Click to expand...

It doesn't really matter that IA "CC1 Off" is set to "1" for most of the switches as long as "CC1 Num" is set to "OFF", does it? Without a CC Num set, the MFC wouldn't know what to do with the "1" value anyway is my reasoning.
 
You must log in or register to reply here.
Back
Top Bottom