SysEx ini file Error: Invalid text

12 posts / 0 new
Last post
spaceranger's picture
SysEx ini file Error: Invalid text

Hi folks, first post to the forum, and I'm really impressed by the depth of the BC Manager software and grateful for Mark's efforts on it. But I've run into a bit of a snag in my attempt to define a sysex ini file for an Axe-FX II XL device. When I start BC Manager, it complains that it cannot load the ini file due to "Invalid text" and I don't know what text it considers to be invalid. I loaded the file just fine without the error when I removed the parameter definitions so it appears to be something about that.

Here's what I have in the ini file right now, I called it "Axe-FX_II_XL.ini":

ProgramName=BC Manager
ManufacturerID=00 01 74
ModelName=Axe-FX II XL
FileAuthor=Michael LaMeyer

; Insert parameter definitions below
{ Amp1
6A 00 01 00 | 00 00 00 - 7E 7F 03 | val14.20 val7.13 val0.6 01 ;Amp1 Input Gain

I want to organize a large number of FX block parameter sets so I'm using the braces for sections, and those aren't the problem either because I removed the braces and still got the error when I started BC Manager.


Here's a single sysex message that I captured that was sent from the Axe-Edit software to the Axe-FX device, for the same Input Gain parameter that I've attempted to define properly in the ini file above:

F0 00 01 74 06 02 6A 00 01 00 6D 61 00 01 67 F7


Here's the anatomy of the message, the LS byte is always first for each element:

F0 = sysex start, of course

00 01 74 = Manufacturer ID

06 = Model ID (Axe-FX II XL)

02 = Function ID (this indicates that the sysex message is a "set parameter" message, and this byte will always be the same for everything I define in the ini file)

6A 00 = FX block ID (this indicates the target FX block for the message, in this case the Amp1 FX block; this ID will be different for different FX blocks such as compressor, cabinet, delay, reverb, etc.)

01 00 = Parameter ID (this indicates the specific parameter to set within the target FX block, in this case the parameter is Input Gain, and each parameter has its own unique ID here)

6D 61 00 = Parameter value (see Axe-FX wiki snippet below for details on this)

01 = the "Set" byte, indicating that the message is to set the value of the target parameter, and every parameter definition in the ini file will have this same byte here

67 = checksum byte (see below Axe-FX wiki snippet regarding the checksum detail)

F7 = sysex end


Here's a snippet from the Axe-FX wiki concerning the format of the sysex for setting the value of a parameter:


Message format:

0xF0 sysex start
0x00 Manf. ID byte0
0x01 Manf. ID byte1
0x74 Manf. ID byte2
0x03 Model #
0x02 Function ID (2)
0xdd effect ID bits 6-0
0xdd effect ID bits 13-7
0xdd parameter ID bits 6-0
0xdd parameter ID bits 13-7
0xdd parameter value bits 6-0
0xdd parameter value bits 13-7
0xdd parameter value bits 15-14
0x00 0=query value, 1=set value
0xdd checksum
0xF7 sysex end


And here's a snippet from the Axe-FX wiki concerning the checksum:

  • The Axe-FX II units require a checksum to be added to the end of the SysEx string that is sent to it (before the terminating F7 byte) as a verification step.
  • In order to calculate the checksum, you basically have to XOR every byte from the start of the SysEx message, up to the character BEFORE the terminating F7 byte. For example, to send the following SysEx message (to fetch a preset name):

F0 00 01 74 03 0F F7

We would have to XOR all the byte values from the starting 'F0' to the '0F' which is the second last byte:

0xF0 ^ 0x00 ^ 0x01 ^ 0x74 ^ 0x03 ^ 0x0F = 0x89

Then, we would need to strip the leftmost bit from the result (by ANDing it to 0x7F):

0x89 & 0x7F = 0x09

And, we add this byte (actually, a septet now) to the end of the SysEx string, BEFORE the terminating F7:

F0 00 01 74 03 0F 09 F7

Obviously, in a 'static' SysEx message like above, you do not have to recalculate the checksum each time as it will always be '09' as the rest of the message does not change, but if you are sending a SysEx string to change a parameter value etc. then you will have to calculate the checksum on the fly as byte values towards the end of the SysEx string will be different each time.

I left the Command byte empty in the definition file because I wasn't entirely sure what to do about the Device ID (I'm not clear on what that should be here and it doesn't seem like the Axe-FX uses a Device ID in the sysex messages anyway), and I'm trying to insert the Function ID byte (0x02) there instead because that's going to be the same for everything, and I'm inferring that doing it this way will result in that Function ID byte being inserted directly after the Model ID byte, which is where it needs to go.

Perhaps the way I've defined the 'val' elements here is incorrect? Although the Axe-FX only uses bits 14 and 15 from the MS byte, it does appear that a full byte is sent. But perhaps val14.20 isn't a valid definition here?

I appreciate any suggestions or pointers here, thank you!

Mark van den Berg
Mark van den Berg's picture

Hm, I agree that the error message isn't as informative as it could be - I'll see if I can improve this in a future version of BC Manager.

Anyway, the reason for the error message is that the BCF and BCR can only work with 14-bit values.
So your suspicion that "val14.20" doesn't exist is correct. See BC MIDI Implementation.pdf, section 14.6.1.
Moreover, MinValue - MaxValue can't be "00 00 00 - 7E 7F 03". Only two bytes are allowed here. See the BC Manager manual, section 18, subsection 2a.
So you'll have to work around this limitation of the BCF/BCR somehow, for instance by hard-coding the least significant byte as 00. Alternatively you can hard-code the most significant byte as 00, but of course that limits the parameter range.
And remember that MinValue and MaxValue use MSB notation: bits 7-13 of the value need to come first.
Another point: the message format on the wiki you're quoting indicates that the parameter value's bits are to be sent in the order 0-6, 7-13, 14-15. This means that "val0.6" must be put in front of "val7.13".
So you could end up with something like this:
6A 00 01 00 | 00 00 - 03 7F | 00 val0.6 val7.13 01 ;Amp1 Input Gain
So the BCF/R's val0.6 here functions as the Axe-FX's bits 7-13, and val7.13 functions as bits 14-15.

Considering the specs you're quoting, I agree about your solution of having the Axe-FX's "Function ID" masquerade as DeviceID. However, it would be better if BC Manager's ini file protocol "simply" supported FractalAudio's SysEx format (assuming they use this method for all their devices). Part of this support could be that BC Manager automatically adds the "Set" byte (immediately before the checksum).

By the way: I don't understand why FractalAudio use this Set byte: doesn't its meaning duplicate the meaning of the Function ID byte?

One more thing: this is the first time I've come across a device using the BCF/R's checksum method 3 ("cks-3"), so thanks for bringing this to my attention!

spaceranger's picture

Thank you for responding so quickly! Shucks, I overlooked the bit depth limitation, but makes sense and although the workaround doesn't allow the full resolution of the parameter, at least it should work well (and better than 0-127 resolution like so many devices only support).

I originally had the LS bytes first, as you corrected, and then I double-guessed this in my flailing to find a quick and simple solution.

The Set byte may also be 00 which makes the message a "query parameter value" message rather than a "set parameter value" message. The parameter value bytes are simply all 00 for a query message (or if they're set, I suspect that they're ignored).


Mark van den Berg
Mark van den Berg's picture

I still don't quite see the need for the Set byte: why didn't Fractal Audio simply define Query as a separate Function ID? That would have saved one byte, wouldn't it? Anyway...

I've made a test version of BC Manager with the following new features:

  • Error messages concerning ini files now mention the line number where the error occurred, and on top of that some error messages have become more informative. For instance, instead of your original message "Invalid text", you now get "Line 22: Invalid MinValue", which is a "slight" improvement smiley
  • The DevicePosition parameter can be "None", and in this case the MinDevice, MaxDevice and DefaultDevice definition lines must be completely removed. This accommodates any device (like the Axe-FX) that doesn’t use a Device parameter in its SysEx messages. So for the Axe-FX you no longer have to assign the Function ID (02) to MinDevice, MaxDevice and DefaultDevice; instead, you only have to specify "Command=02", which is much more natural.
  • The new global AfterData parameter specifies any fixed data bytes to be sent after the variable data bytes (but before the checksum, if present). This means that you no longer have to append "1" to each parameter definition line, but only have to put "AfterData=01" in the header.

So please let me know which operating system you're using so I can upload the test version for that OS.

spaceranger's picture

Thank you! I just saw this reply now, sorry I have not replied sooner (I was busy defining lots and lots of parameter definitionslaugh). I am running Windows 10.

I popped back in to ask another question if you have some time to consider this problem. Perhaps there's a simple correction I can make. I am able to assign the definitions to encoders within B-Control and successfully push my custom preset to the BCR2000 (as far as I can tell, B-Control reported no errors). But the encoders that I assign the sysex parameters to do not seem to transmit midi data. I successfully defined 8 encoders to send CC messages, and I tested in mode S-4, with the midi out of the Axe-FX patched into the midi in of the BCR2000 and the midi out port A patched into the midi in of the Axe-FX. The encoders assigned to CC messages transmit just fine, the encoders assigned to the sysex parameter definitions do not send any data. Alas!

Here's an example from the preset as saved to a bcr file:

$encoder 33
  .showvalue on
  .mode 1dot
  .minmax 0 511
  .tx $F0 $00 $01 $74 $06 $02 $6A $00 $01 $00 $00 val0.6 val7.13 $01 cks-3 0 $F7 ;Amp1 Input Drive

Can you suggest any reason that the encoders may not be transmitting the sysex data, or point out anything that I might be missing here? Thank you!

Mark van den Berg
Mark van den Berg's picture

Here is the executable of BC Manager 3.2.0 Alpha 1:
(The final version of 3.2.0 will probably be released next year.)

To install:
1. Extract BCMan3.2.0a1.exe from
2. Copy BCMan3.2.0a1.exe to the directory of your current BCMan.exe. Normally this directory is "C:\Program Files[ (x86)]\Mountain Utilities\BC Manager", so you'll need administrator rights to do this and the next two steps.
3. Rename your existing BCMan.exe to something else.
4. Rename BCMan3.2.0a1.exe to BCMan.exe.

You should make the following changes to the header of your Axe-FX's ini file:

  • Change ProgramVersion to 3.2.0.
  • Change DevicePosition to None.
  • Remove the MinDevice, MaxDevice and DefaultDevice lines.
  • Set Command to 02.
  • Insert AfterData=01 between the AddressLength and ChecksumMethod lines.

So the header should look like this:
ManufacturerID=00 01 74
ModelName=Axe-FX II XL

And you should remove the final 01 from the parameter line.

Let's hope I haven't missed anything - always a possibility with these complicated protocols...

I'll look at your new question later.

Mark van den Berg
Mark van den Berg's picture

The reason your encoder doesn't send anything (and its LEDs remain off) is that $encoder (among other things) clears the encoder's four Resolution parameters.

So your BCL code should include a line like .resolution 96 96 96 96 (or simply .resolution 96):

$encoder 33
  .showvalue on
  .mode 1dot
  .resolution 96 96 96 96
  .minmax 0 511
  .tx $F0 $00 $01 $74 $06 $02 $6A $00 $01 $00 $00 val0.6 val7.13 $01 cks-3 0 $F7 ;Amp1 Input Drive

In BC Manager's encoder dialog box you can simply achieve this by clicking on 'Set standard resolutions (96)' on the General tab.

For standard output definitions (e.g. Control Change) a .resolution line isn't necessary because the .easypar statement automatically assigns 'reasonable' values to the four Resolution parameters.

See section 17.3 of BC MIDI Implementation.pdf for all the details.

spaceranger's picture

RE: 3.2.0 alpha:

Thank you so much for this build! I'll test it out and let you know what I find. I may need a week or so to get the time to bang at it.

RE: encoders:

Cool, ok, that makes sense. I wasn't sure what those values should be, and I haven't got my head wrapped around what the encoder values mean here. When the values that I'm assigning only go from 0 to 511, 96 seemed like a fairly high number (I thought it represented the values between every 'click' of the encoder knob turning, but that must be the wrong idea .. I think?).

I'll test this out with the non-alpha just to get a baseline that I can roll back to, and then make a copy of the parameter definition file to reconfigure and check out the alpha version.


Mark van den Berg
Mark van den Berg's picture

Quoting from BC MIDI Implementation.pdf: "The four arguments indicate the amounts of value change per 360-degree rotation."
This means that for a standard Control Change parameter ranging from 0 to 127, the standard resolution of 96 yields a rotational range of 480 degrees, i.e. 1 1/3 full rotation.
And with your parameter range of 0-511, resolution 96 yields a rotational range of 1920 degrees, i.e. 5 1/3 full rotation. So you probably want to raise the resolution parameter to reduce the number of full rotations. But of course the optimal value depends on what the parameter actually does.

spaceranger's picture

Got it! I'm an avid proponent of RTFM, and rather proud of it, but I'm disappointed that I've missed so much in the manual. :(

Thanks for the direction!

spaceranger's picture

I've been enjoying using the BCR2000 to tweak all of the parameters in the Axe-FX for over a week now. I've shuffled some things around a bit in my bcr files and have some presets that now let me tweak pretty much everything for the amp, cabinet, drive, compressor and gate FX. Thank you so much for your help Mark! This thing's off and racing now. However, I haven't broke out the alpha yet and I owe you for that, so I'm just posting an update of where I'm at here and to let you know that I will be testing that and updating you on the results by this weekend. Cheers!

spaceranger's picture

Over-committed and under-delivered here, sorry, but I did finally get a chance to test your alpha and the changes seem to work fine. I performed all of the steps you outlined in the instructions above concerning the editing of the .ini file, and then added a new BCR9000 preset using the new definitions. All sysex was fomatted properly as far as I looked. I'll keep running on it and will let you know if I run into anything. I will likely not be able to update you until next month. Thank you again!