Behringer Pro-800

Behringer Pro-800 preset

4 Likes

Struggling with getting updated controls from patch request; maybe someone smarter than me can have a look. I think I’ve managed to make the correct sysex string to request patch; but not how to use the returned data to update the preset.

Some sysex info for the Pro-800 to be found here

Hi, I might be of help in a couple of weeks. I’m current occupied with other matters than making music, but as it happens the Pro-800 arrived at my doorstep this week. i’ll try somewhere mid or end october to deepdive in its SysEx and your preset, and then see where I can be of assistance.

Keep up the good work

3 Likes

Just did some tests on your preset: check the midi cc you use.Most of them you used in the ‘fine’ range starting at 80,whereas you better use the coarse one, typically 72 down ,starting at 8.
For the on/off parameters do use the values 64/0 instead if 127/0.

Those 2 changes will make your preset respond to changes you apply to the Pro-800.
Try it out please .

1 Like

Hi Magnus @fragletrollet ,

I’ve made my own preset version so far, but did not try any SysEx parsing yet. Your lua code is still present in it, but I haven’t investigated at this moment, so it is commented out.

I’ve figured out all parameters the last firmware 1.4.1 of the Pro-800 is able to deal with, and added them to the preset. That might be of some help for finding the exact values the MIDI CC is using for your preset, I hope.

Now changes to the Pro-800 will be reflected in the E1 and vice versa. The only exception is the ARP. The E1 controls the ARP, but the Pro-800 doesn’t send any instructions to the E1 for this.

On the second page you’ll find a more elaborate patch select, with some lua attached to it:
https://app.electra.one/preset/g5UvwLpZ373g98pKQ2ZK

By the way; did you find what ‘VIBRATO TARGET’ should be doing (CC71) ? I couldn’t hear any change.

**EDIT : **
OK , some more info on the partial parsing that is already done.

Thanks for providing the info about the SysEx. That was quite helpful.
So as usual I started setting up my patch request selectPatch. In it I defined the 2 bytes needed to recall a patch with SysEx: progNumLSB and progNumMSB.

    progNumLSB = (bank*100+progNum)%128
    progNumMSB = (bank*100+progNum-progNumLSB)/128

In the patch request itself, you will notice I use two functions in order to recall exactly the SysEx of the patch (both in the device editor as well as in lua):

midi.sendSysex (devPort, {0x00, 0x20, 0x32, 0x00, 0x01, 0x24, 0x00, 0x77, progNumLSB, progNumMSB})

Once this was in place I tried to parse the first variable ‘Frequency A’, but that worked out much harder than anticipated. So I left the idea for a while and worked on reverse engineering all the booleans (on/off). It worked as a charm. Whereas the MIDI CC required values 0 and 64, SysEx uses values 0 and 1. But by assigning them to position 6 in the byte of the parameter, the 1 became 64. Easy peasy
image

Next in line are the selection lists. By listening in on the sent CC commands from the Pro-800 via MIDI-OX, it was soon discovered the Pro-800 uses like all the available space between 0 and 127 to subdivide the desired options in equal spaces.
So parameters with 4 values use 0, 32, 64, 96, which was still easily translatable from SysEx values 0-3 to 0-96 by positioning the SysEx bits starting at Byte position 5 of the parameter
image
but that was about it.

Other lists, like the LFO Shape list, has 6 options, each 22 values apart in the MIDI CC #57. Not easy anymore to directly translate the SysEx values 0-5 into MIDI CC values 0-110.
You can resolve this by parsing the SysEx values in a secondary virtual parameter (I even give it the same parameternumber but a different type), which will be made invisible, where the values of the option list equal the values found in Sysex. By assiging the following function multiply22 to this virtual parameter, I can use it to feed the real CC7 parameter #57 with the right values, whenever the sysEx is being parsed:

function multiply22(valueObject, value)
  local message = valueObject:getMessage ()
  local parameterNumber = message:getParameterNumber ()
  --print ("multiply22 parameterNumber="..parameterNumber)
  --print ("multiply22 value="..value)
  parameterMap.set (deviceId, PT_CC7, parameterNumber, value*22);
end

Using this method, I’ve now converted all boolean and option lists. So now a pattern starts being visible. The pro-800 is using 8bit Bytes, and seems to do this by creating blocks of 8 Bytes, containing the data of 7 8-bit values:
Every SysEx bytes only has a payload of 7 bits, and the 8th bit is then stored somewhere in the byte that preceeds or succeeds a block of 7 bytes making a total of 8 Bytes (of 7 bits each) in the Sysex, carrying 7 Byters (of 8 bits each) as information.

By just parsing booleans and options that do not need all 8 bits to works, that pattern reveals itself in the parsing assignments.

That’s all for today

1 Like

Thanks for the insight, although it’s still a bit over my head :slight_smile:

Regarding the preset using the “fine” version of the parameters; i first mapped to the coarse and found the control way too coarse (hehe), and mapped to the fine parameters it felt natural, and I had no problems with covering the whole range while being able to hone in on a specific range. But I’ve not had a lot of time actually using the preset, so maybe some destinations act differently.

Anyhow, cool to see progress on your side!

That’s weird, can you give me an example of a midi CC control in your preset, that covers the whole range (please do a test and let me know). Because if that works, I must have overlooked something?