Midi CC Messages Ignored

steadystate

steadystate

Fractal Fanatic
I originally posted the following under the Bugs topic, but moved it since the behavior described may be intentional. I am reposting here to see if someone can devise a better workaround than the cumbersome and inefficient method I currently use.

I am using external controllers ( External 1 through External 8 ) to allow a midi foot controller (a Lake Butler Midi Mitigator, considering an MFC-101) to change the value of various Axe parameters (all with PC RST enabled) by sending cc messages to the Axe. Here is my problem…

I use a preset switch on the foot controller to send a program change to the Axe, and then use subsequent preset switches (or IA switches if available) to send cc messages to change the value of various parameters within the recalled program (the Axe calls them presets).

When an Axe preset is recalled, the Axe parameters will all return to their respective stored values as expected. However, ****a subsequent cc message will be ignored if it is the same value (or even close to the same value) as the last sent before the program change occurred****.

For example:

I turn the Axe FX on.
I recall a preset with the target parameter stored at a value of 30.
I send a cc value of 0; the parameter is set to minimum (as expected).
I recall the preset; the parameter returns to the stored value of 30 (as expected).
I again send a cc value of 0; the cc is ignored and the parameter stays at 30.

If I then send a cc value of 127; the parameter is set to maximum (as expected).
I recall the preset; the parameter returns to the stored value of 30 (as expected).
I again send a cc value of 127; the cc is ignored and the parameter stays at 30.

If I then send a cc value of 64; the parameter will move to mid position (as expected).
I recall the preset; the parameter returns to the stored value of 30 (as expected).
I send a cc value of 64; the cc is ignored and the parameter stays at 30.

I send a cc value sufficiently different than 64; the parameter moves to the correct corresponding position.
Etc…

Therefore, I cannot rely on cc messages to correctly control the target parameters of that preset. Also, if a different preset is recalled that uses the same External Controllers, a cc message may or may not work depending on the value that was last sent to the previous preset.

The workaround I use is to program each switch of my foot controller to send out two cc messages of different values (for each target parameter), with the latter being the desired target value. If I want to change 4 parameters with a switch, I have to program that switch to send out 8 control change messages if I want to be sure all parameters will be set to their target values.

Although my foot controller allows unlimited command strings per switch, it does not have unlimited memory. If I buy a controller that allows fewer commands per switch, my problem will be compounded.

I understand this design probably exists for a reason (perhaps so rocker-type pedals don’t slightly move and change a parameter unintentionally), but I would greatly appreciate any brainstorming the forum can offer that could eliminate the need to double the number of cc messages required when using a footswitch-type controller. An option to allow repeat duplicate cc values to change a parameter would solve the problem. Maybe this option exists and I simply missed it.

Thanks,
Mark
 
Last edited:
Is there an option on your controller to put a pause in between messages? If so try a break between the calling the preset and the request for the parameter change.
also, there is a setting in the AxeFx Midi menu called "Ignore Redundant PC" it doesn't sound like that is exactly related but it might be worth a try...
I used to send tap tempo by way of repeating the same switch that called up my preset (my controller would hold back the initial cc number and send the tap tempo cc for subsequent pushes) so it seems like the AxeFx can receive the same message repeatedly if that is any indication.
 
Last edited:
The problem isn't that cc messages are being ignored because they occur too soon after a program change. After the initial program change is sent, the subsequent footswitches are sending only cc data, with no program changes. Besides, one of the great things about the Axe is that it *can* respond to cc messages even if they are sent immediately after a program change in the same command string. That is awesome.

The problem is that a cc message is ignored if that cc number was last sent with the same value, even if it was last sent before the program change occurred. The program change recalls the stored parameter value, but then the cc message is ignored when I press the footswitch unless I send a different (and unwanted) value. So I have to send two cc messages (one dummy value and one correct value) to set the parameter to the desired value.
 
I programmed the Roland FC-300 pretty heavily with the Axe (b4 my MFC arrived) and have not observed this behavior. Does it work it you send the same CC a 2nd time (i.e. press the button twice) ?
 
What is the foot controller itself spitting out? Is it not resending the CC value or is it the AxeFX not responding to redundant info?
 
Would disabling PC RST conflict with how you want things to work? If you can send enough CCs for all externals used along with the initial program change, that could be an alternative. With PC RST on the double CC method is the only workaround.

For s0c9 & shasha:

The issue is that when PC RST is enabled, the modifier source has to change from the last received value by a few percent before the parameter begins to reflect it. If your controller only sends 0/127 for IAs and sends them at preset changes too, you won't encounter that.
 
Last edited:
Bakerman said:
Would disabling PC RST conflict with how you want things to work? If you can send enough CCs for all externals used along with the initial program change, that could be an alternative. With PC RST on the double CC method is the only workaround.

For s0c9 & shasha:

The issue is that when PC RST is enabled, the modifier source has to change from the last received value by a few percent before the parameter begins to reflect it. If your controller only sends 0/127 for IAs and sends them at preset changes too, you won't encounter that.
Click to expand...
Bakerman:

I typically use the first preset switch in a bank to send a program change, with all parameters stored at the desired inital values for the tone I want. This is usually the 'core' tone of the song.

I then use subsequent switches to send cc messages to change the parameters and modify the tone for solos, breakdowns, level changes, etc.

I then bounce back and forth between the program change switch and the cc switches. This way, I can get back to the core tone with a single program change. Disabling PC RST would negate this. However, your suggestion may work with or without PC RST enabled...

If, immediately after the program change in the command string in the inital switch, I program cc messages for every parameter I intend to modulate, each with a value corresponding to the stored value, I may only have to enter each cc once (with the correct value) when programming the subsequent switches. This should work even with PC RST enabled since the Axe seems to respond to (and remember) cc messages sent instantly after a program change.

I wanted to avoid sending a string of cc messages with the program change just to recall the program and have subsequent cc messages work. Being able to defeat this behavior would be ideal (it would eliminate up to 8 cc messages per program), but this is better than what I'm doing now. Thanks.


To s0c9:
Are you sure you aren't experiencing the same behavior?
 
Last edited:
Do any switches send the program change for this preset, other than the one you reuse to get the initial settings? If not and you have the main switch send CCs for all externals, it wouldn't really matter if PC RST is on. (If ignore redundant PC is on it also wouldn't matter if the others sent the PC.)

I think the actual PC RST issue still remains regardless of whether a CC happens right after a PC--if the new value after a PC is close enough to the last before the PC the parameter won't be taken over by the new one, so then the next one (if close enough) also won't take over, etc. If your IAs all switch to sufficiently different values from the initial ones that wouldn't happen.
 
My guess is that it's actually the controller not sending duplicate messages. The Axe-Fx code doesn't examine if a CC value is the same as the previous message.
 
Cliff, this is definitely something caused by how the Axe-FX deals with externals as modifiers. Say the last value of an external's CC was 127 and then a program change happens. In the new preset if there's something with that external as modifier and PC RST on, any values for that CC between 121 (I think--was moving a pedal carefully and checking Midimate CC display vs. Axe screen to test this) and 127 won't have any effect on the parameter. When you reach a different enough value (120 or lower) it finally jumps from the stored value to reflect that.
 
Bakerman, this is exactly the behavior I am seeing. The repeat cc message must be different from the preceding one by a few value increments for the message to change the parameter.

I'm using a Lake Butler RFC-1 Midi Mitigator (old but awesome). It is most definitely sending out the cc changes each and every time a switch is pressed. If the Axe doesn't examine the cc value, then I'm stumped.

Bakerman said:
Do any switches send the program change for this preset, other than the one you reuse to get the initial settings? If not and you have the main switch send CCs for all externals, it wouldn't really matter if PC RST is on. (If ignore redundant PC is on it also wouldn't matter if the others sent the PC.)
Click to expand...

No to the first question. You are correct on the second and third sentences.

Bakerman said:
I think the actual PC RST issue still remains regardless of whether a CC happens right after a PC--if the new value after a PC is close enough to the last before the PC the parameter won't be taken over by the new one, so then the next one (if close enough) also won't take over, etc. If your IAs all switch to sufficiently different values from the initial ones that wouldn't happen.
Click to expand...

I agree. If I program the initial switch to send the PC and all required cc messages corresponding to the parameters' stored values, PC RST is irrelevant. I *think* the cc messages are ignored even if PC RST is disabled. In any case, I see no advantage to turning it on or off if I need to send cc data upfront with the PC.
 
Last edited:
Bakerman said:
Cliff, this is definitely something caused by how the Axe-FX deals with externals as modifiers. Say the last value of an external's CC was 127 and then a program change happens. In the new preset if there's something with that external as modifier and PC RST on, any values for that CC between 121 (I think--was moving a pedal carefully and checking Midimate CC display vs. Axe screen to test this) and 127 won't have any effect on the parameter. When you reach a different enough value (120 or lower) it finally jumps from the stored value to reflect that.
Click to expand...

That's exactly the way it is designed to work. The new value must be 5% different than the previous value otherwise whatever value the pedal is at will immediately override the "PC RST" value.

The idea is that the parameter is set to a value when you recall the patch. You then have to move your pedal a bit (5%) to regain control of the parameter.

This is done for two reasons:
1. Many MIDI controllers send the state of their expression pedals along with the PC message. If the behavior weren't as described the stored parameter value wouldn't "stick".

2. Many MIDI controllers have "noisy" expression pedals where the value tends to bounce around a little. This, again, prevents the stored value from being lost.

The O.P. simply needs to turn off PC RST for those modifiers.
 
As my previous post indicated, I figured this behavior was by design. My controller only sends out pedal info if the preset switch tells it to, so I don't have to worry about these points. Other controllers, or pedals connected to the pedal inputs of the Axe, could cause problems. Being able to adjust that 5% to 0% would be pretty boss.

If I turn off PC RST, the patch won't be recalled as stored (which is my wish) when I press the PC switch. Sending cc messages immediately after the PC in the same command string seems to work. As long as I can get it to do what I need it to do, I'm happy. I was just fishing for suggestions. Thanks all.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom