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?