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
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 .
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
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
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
Thanks for the insight, although itās still a bit over my head 
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?
Hey @NewIgnis I was working on my own solution for this today. Iāve been stuck trying to get the Pro-800 to respond to the Patch Request, I seem to be doing what you are doing too.
Do you have code you could share so that I could learn from it by any chance?
Here are two non-Behringer documents I used as inspiration / reference.
Other than that, there were some discussions on th Pro-800 thread on GearSpace.
But thatās about it.
Have fun !
Preset-Structure-Document_BE_0718-ABF_PRO800_A3.pdf (160.2 KB)
pro-800-remote-documentation.pdf (767.5 KB)
Hoi David,
sorry I didnāt realise my Pro-800 preset wasnāt public.
Itās made about 1,5 year ago, so my mind isnāt fresh on the details.
Youāre the best! I have a solution thatās mostly working so Iām going to take a look at yours now and future out what youāre doing differently to me.
Iāll likely combine the two and post it here for you to take a look.
Regarding foggy memory - I totally get it, this is my first SysEx project and itās more complicated than I expected.
You surely didnāt pick the easiest one! The combination of Behringer logic with Gli-Gliās MIDI approach has added quirks, I hadnāt met before in MIDI land. Certainly the quirk where fine controls overlap with the range of coarse controls.
But I canāt memember if and how and I dealt with that. The preset though is very useable.
By the way I have two Pro-800: one of them is bidirectionally connected via USB to the rest of the MIDI gear. The second one has its MIDI in connected to the MIDI out/thru of the first one.
They now both interact to commands from the E1 or the first Pro-800, but I can offset those settings on the second one if I want to.
Further more the first is panned hard left, the second one hard right.
The end result is fantastic, and similar to UDOās binaural approach is I have it on the Gemini. But at a fraction of the cost.
I am so sorry I didnāt get back you sooner!
So, youāre E1 UI and integration for the Pro-800 is really good. I can now clear the two Pro-800s off my table and keep the E1 in the center. I donāt have much space so this change wins me back a lot of room.
So where I went wrong is I basically wrote 640 lines of LUA to parse the incoming SysEx manually thinking thatās how I needd to do it. I see now that the E1 offers you a dump probe (the has to be a better name for that) to assign bytes to different midi CCs etc. I donāt know how to use it however, I tried and I got very little data back and wasnāt quite sure how to figure out what byte was doing what. Do you mind explaining how you approached the problem and if there is documentation on this that I should have read please just point me to it - as I donāt want you to waste your time.
I really like your UI also, especally the way you created a fixed position Patch ātoolbarā between your pages, thatās nice and give sme ideas on how I might add on to that too.
My plan is to have the E1 as the center of my dawless setup with just the Line mixer, E1 and Keystep 37 and Digitakt2 on the table and all synths being out of view. I donāt have a lot of synths and many I do have are very basic and donāt have sysex support or even bidirectional Midi CC.
Thank you again for making your great E1 Pro-800 integration public. Its a big contribution to the platform. 
(P.S)
you recommened I look at the Electron Overhub for its Multi TT technology, I liked it but was disapointed that it didnāt come with a power supply. Insted I got this one 7 Port USB 3.0 Hub - LINDY EU which does also have Multi TT technology, but critically comes with the beefy 12V 3A power power supply to drive all the attached gear. Thanks for the pointer, that was helpful also.
Nice find, that Lindy HUB. whatās its price?
As said, you didnāt pick the easiest synth to parse. The good news indeed is you can parse using the standard parsing tool that is built into the E-1 .
The bad news is that Pro-800 isnāt using a 1 byte = 1 parameter approach, but is using an 8 bit approach for some parameters that canāt be placed in a single MIDI byte which lony offers 7 bit space for data.
This is typically resolved to spread 7 parameters of 8 bits over a grou p of 8 bytes, where the first byte containts the most significant bit of those 7 parameters, and the other 7 bytes then contain the 7 least significant bits. However Behringer made it extra complex, because in most cases the lowest bit didnāt even come into play, so I ignored it anyways.
How dit I know? well be observing the traffic coming from the Pro-800 via the E1 capturing mechanism, combined with the MIDI info we get from Behringer or other sources, and then combined with the gained experience of parsing synths.
Take a look at the example below, which shows how the FINE ENV Amount CC7 paramter 89 is parsed out of a most significant bit, followed by 6 less significant bits, and skipping the 8yh lowest bit.
I made a series of articles in this forum about parsing MIDI with a step for step approach.
. Might be of help to you.
I usually tag my presets as well with āpatch parsingā, so that might help you find other examples on how to parse.
@NewIgnis thank you for explaining what needs to be done. What youāre desceibing makes sense to me and I feel I can start to practice it now. The plus side of writing my own SysEx Lua parser is I learned a lot 
I am very gratful that you also wrote articles about this process. I will make a cup of tea and read over them when I get home.
I actually bought a Waldorf Blofeld and am using your āpatch parsingā E1 integration with it - sooooo much more fun. This is another area that the Electra E1 shines. It makes powerful synths otherwise hampered by menu diving or bad UI/UX a delight to use. Thank you for also making this Blofeld integration. I love what you did here.
The Lindy HUB is 55 Euro including the power supply. I am based in Germany so I got it from Thomann. Its a good price I think, It isnāt made of metal like the Electron device but its build quality is still good.
Edit: Changed word āoneā to āanotherā and fixed typo.