Guide/tutorial for patch request button?

I’ve made a preset for my Roland JX-3P with the Kiwi mod that allows for full Midi CC and Sysex control. I have everything working as far as parameter control, but I would really love to be able to use the top right “Patch Request” button on my Electra One to update the parameters with the current JX-3P settings.

I found someone online that had made a Ctrlr panel for the Kiwi-3P, and they mentioned this…

"The panel updates the parameter settings on receipt of an Edit Buffer message from the Kiwi-3P. At various places in the panels scripts a command to send an Edit Buffer request are written in, such as when a new patch is selected.

The request is the Sysex message: f0 7f 7f 7f 60 01 00 03 f7

Indeed when parameter settings on the panel are saved to the Kiwi-3P these are gathered from the various knobs and compiled in to another Sysex dump that is sent to the Kiwi-3P, so you setting in the Kiwi’s Edit Buffer are overwritten."

I’m not really sure how to implement this though, as just using that Sysex message didn’t seem to do anything for me (though I probably was implementing it incorrectly…)

I’ve attached a PDF with the rest of the Kiwi-3P sysex info in case that is more helpful than the request sysex message above. If anyone can put me on the right path that would be awesome, thanks!

Kiwi-3P-sysex.pdf (80.1 KB)
KIWI-3P.epr (16.9 KB)

1 Like

I guess no one has any info that might help?

@four_corners, I do :slight_smile: I will get in touch with you and we will get your JX-3P going. Also, tutorial is almost completed. I will publish that on Electra One online documentation site next week.

Awesome, thanks Martin! I know you are very busy with plenty of other Electra One work, so I really appreciate all your help.

Are the new Pad control type what should be used for this? I can maybe try the Sysex message I found online, f0 7f 7f 7f 60 01 00 03 f7, to see if that works.

Hi, yes let’s do that. Please create a pad that will trigger this message. It is JX3P request for edit buffer sysex dump. JX3P will respond with a sysex message that has all the patch data. Please catch that response message with a MIDI monitor / sysex program program on your computer and send it to me, I will do the first steps. I will use it to finalize the tutorial document (and as work on it I will add it to your JX3P preset)

please note, you must enter the sysex message in following format in the preset editor:

{ “7F”, “7F”, “7F”, “60”, “01”, “00”, “03”}

Thanks for the help!

I used both MIDI Monitor, and SySex Librarian, and this is what came back…

f000 2116 6001 0004 0040 4c6f 7720 5374
7269 6e67 7320 2020 2020 2020 2020 003f
3f00 3f00 3f4c 3f00 3f00 400a 0847 0000
4425 3f00 0009 006b 2419 246b 2301 640a
0179 0a00 2e03 2b00 003f 0000 0000 030c
0000 0000 6f00 0000 0000 3f3f 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 f7

If a Sysex file of that is preferable, let me know and I can send that instead.

Let me know if you need anything else!

To add to my last response:

I’m not sure if this is more helpful, but this is a screenshot from MIDI Monitor

this is fine, I can perfectly work with that. Thx!

Thanks Martin! Looking forward to it.

I know you are very busy with everything, I was just curious if you’d made any progress with the tutorial. Thanks!

Quick question, I noticed on the SysEx parse section of the developers documentation, you mention you are currently adjusting the Electrion one SysEx parse, so it is just a reference document currently.

My question is, are you planning on adding the request/response sysex parse to the online editor, or will it still be something needed to be done in a json/text editor? It would be awesome to be able to implement patch request to the editor, but I understand that is probably fairly complex.

Looking forward to the tutorial document, as I have a few synth presets ready for this implementation.

Hi, the sysex parser editor is on our development list. The document I posted is still a a “work-in-progress” version, but I think I will complete it this week. Do you want to try the editing the JSON epr files? Or do you prefer waiting for the editor?

I think I’ll be able to handle editing the JSON epr file manually, so long as you might be able to help me by setting up the first 2-3 parameter parsing so I can test it and see it working in action. That way I at least have a few confirmed working request/response parameters that I can then use as a template for the rest of the parameters…

I have made an example preset with 3 controls of Kiwi JX3P and added a patch definition that instructs Electra how to fill these the controls with values out of the SysEx dump.

SysEx parsing example

{
   "version":2,
   "name":"KIWI-3P",
   "pages":[
  {
     "id":1,
     "name":"Page 1"
  }
   ],
   "groups":[
  {
     "pageId":1,
     "name":"DCO 1",
     "bounds":[
        0,
        16,
        486,
        16
     ],
     "color":"FFFFFF"
  }
   ],
   "devices":[
  {
     "id":1,
     "name":"Generic MIDI",
     "port":1,
     "channel":1,
     "patch":[
        {
           "request":[
              "7F",
              "7F",
              "7F",
              "60",
              "01",
              "00",
              "03"
           ],
           "responses":[
              {
                 "header":[
                    "00",
                    "21",
                    "16",
                    "60",
                    "01",
                    "00",
                    "04"
                 ],
                 "rules":[
                    {
                       "type":"cc7",
                       "id":1,
                       "pPos":0,
                       "byte":22,
                       "bPos":0,
                       "size":2
                    },
                    {
                       "type":"cc7",
                       "id":2,
                       "pPos":0,
                       "byte":22,
                       "bPos":2,
                       "size":2
                    },
                    {
                       "type":"cc7",
                       "id":3,
                       "pPos":0,
                       "byte":23,
                       "bPos":0,
                       "size":7
                    }
                 ]
              }
           ]
        }
     ]
  }
   ],
   "overlays":[
  {
     "id":1,
     "items":[
        {
           "value":0,
           "label":"16'"
        },
        {
           "value":32,
           "label":"8'"
        },
        {
           "value":64,
           "label":"4'"
        }
     ]
  },
  {
     "id":2,
     "items":[
        {
           "value":0,
           "label":"Sawtooth"
        },
        {
           "value":32,
           "label":"Pulse"
        },
        {
           "value":64,
           "label":"Square"
        }
     ]
  }
   ],
   "controls":[
  {
     "id":1,
     "type":"list",
     "name":"RANGE",
     "color":"FFFFFF",
     "bounds":[
        0,
        40,
        146,
        56
     ],
     "pageId":1,
     "controlSetId":1,
     "inputs":[
        {
           "potId":1,
           "valueId":"value"
        }
     ],
     "values":[
        {
           "defaultValue":32,
           "message":{
              "type":"cc7",
              "parameterNumber":8,
              "deviceId":1
           },
           "overlayId":1,
           "id":"value"
        }
     ]
  },
  {
     "id":2,
     "type":"list",
     "name":"WAVEFORM",
     "color":"FFFFFF",
     "bounds":[
        170,
        40,
        146,
        56
     ],
     "pageId":1,
     "controlSetId":1,
     "inputs":[
        {
           "potId":2,
           "valueId":"value"
        }
     ],
     "values":[
        {
           "message":{
              "type":"cc7",
              "parameterNumber":9,
              "deviceId":1
           },
           "overlayId":2,
           "id":"value"
        }
     ]
  },
  {
     "id":3,
     "type":"fader",
     "name":"TUNE",
     "color":"FFFFFF",
     "bounds":[
        340,
        40,
        146,
        56
     ],
     "pageId":1,
     "controlSetId":1,
     "inputs":[
        {
           "potId":3,
           "valueId":"value"
        }
     ],
     "values":[
        {
           "min":0,
           "max":127,
           "defaultValue":63,
           "message":{
              "type":"cc7",
              "parameterNumber":10,
              "min":0,
              "max":127,
              "deviceId":1
           },
           "id":"value"
        }
     ]
  }
   ]
}

The most important part here is the patch object in the device:

 "patch":[
    {
       "request":[
          "7F",
          "7F",
          "7F",
          "60",
          "01",
          "00",
          "03"
       ],
       "responses":[
          {
             "header":[
                "00",
                "21",
                "16",
                "60",
                "01",
                "00",
                "04"
             ],
             "rules":[
                {
                   "type":"cc7",
                   "id":1,
                   "pPos":0,
                   "byte":22,
                   "bPos":0,
                   "size":2
                },
                {
                   "type":"cc7",
                   "id":2,
                   "pPos":0,
                   "byte":22,
                   "bPos":2,
                   "size":2
                },
                {
                   "type":"cc7",
                   "id":3,
                   "pPos":0,
                   "byte":23,
                   "bPos":0,
                   "size":7
                }
             ]
          }
       ]
    }
 ]

The request defines bytes of the sysex message that will be sent when the [PATCH REQUEST] button is pressed.

       "request":[
          "7F",
          "7F",
          "7F",
          "60",
          "01",
          "00",
          "03"
       ]

This particular example requests dump of JX3P edit buffer.

The responses array defines sysex messages that are expected to arrive in response to the request. The header lists static bytes at the beginning of the incoming message.

             "header":[
                "00",
                "21",
                "16",
                "60",
                "01",
                "00",
                "04"
             ]

If the leading bytes of the incoming sysex message match the bytes of the header, Electra will start extraction of parameter values out of the message and will assign them to controls. The extraction is done with so-called rules. There are three rules in this example:

                {
                   "type":"cc7",
                   "id":1,
                   "pPos":0,
                   "byte":22,
                   "bPos":0,
                   "size":2
                }

this instructs Electra to get two bits (size = 2), out of 22nd byte of the sysex message (byte = 22). The position of the bits in the byte is 0 (bPos = 0). This extracted value should be stored in parameter 1 (id = 1) of the “cc7” type (type = “cc7”). The position of the value within the parameter is 0 (pPos = 0).

The location of the sysex byte (byte) is taken from the first byte after the header. It means the first byte after the header is byte = 0, second is byte = 1, and so on.

Applying above to the second rule:

                {
                   "type":"cc7",
                   "id":2,
                   "pPos":0,
                   "byte":22,
                   "bPos":2,
                   "size":2
                }

This tells Electra to pick 2 bits out of byte 22 from position 2 and make them value of parameter CC7 #2.

And finaly:

                {
                   "type":"cc7",
                   "id":3,
                   "pPos":0,
                   "byte":23,
                   "bPos":0,
                   "size":7
                }

tells Electra to pick value out of byte 23 and place it to CC7 #3.

I know this might be a little bit too much for start. I am available to help and I am working on the docs.

The Development Sandbox can be used to play around with the preset. Just copy and paste the contents of the file (above) to the Sandbox and modify it as you need.

I do not have JX3P around, so I wrote the example based on the screenshot yu sent me. I would say it could work but I cannot guarantee that.

Also, it is always useful to have ElectraOneConsole running when you experiment with things like this. The Log view can give you insight in what is happening in Electra when you load the preset and when you press the [PATCH REQUEST] button.

For the sake of completeness, this is what I expect to be the parameters I tried to parse:

Hi Martin,

Okay, so I’m kinda getting somewhere, and I at least have some more info to give that might help.

It seems like the Electra One is receiving all the info it needs, but it just isn’t updating on the actual device screen. I decided to simplify the preset you made for me and just have the Tune parameter in it instead of 3 of them, and then changed the Tune parameter from ID3 to ID1.

Here is a screenshot from the Electra One Console…

So I had set the tune parameter on my JX-3P to 70, and then clicked the Patch Request button on the Electra One. As you can see on the screenshot, it says… “setting parameter 1 to 70 (70)

So it seems like it is trying to set the TUNE parameter on my Electra One to 70, but it doesn’t seem to be changing the screen.

When the Electra One console says “setting parameter 1”, that means ID1 on the Electra One, and not the CC parameter number, correct?

If the console says “setting parameter 1 to 70 (70)”, but that does not seem to happen on the Electra One screen, what do I need to do?

{
  "version": 2,
  "name": "KIWI-3P",
  "projectId": "31t1j4SOSzFOErfmJqRN",
  "pages": [
    {
      "id": 1,
      "name": "Page 1"
    }
  ],
  "groups": [],
  "devices": [
    {
      "id": 1,
      "name": "Generic MIDI",
      "port": 1,
      "channel": 1,
      "patch": [
        {
          "request": [
            "7F",
            "7F",
            "7F",
            "60",
            "01",
            "00",
            "03"
          ],
          "responses": [
            {
              "header": [
                "00",
                "21",
                "16",
                "60",
                "01",
                "00",
                "04"
              ],
              "rules": [
                {
                  "type": "cc7",
                  "id": 1,
                  "pPos": 0,
                  "byte": 23,
                  "bPos": 0,
                  "size": 7
                }
              ]
            }
          ]
        }
      ]
    }
  ],
  "overlays": [],
  "controls": [
    {
      "id": 1,
      "type": "fader",
      "name": "TUNE",
      "color": "FFFFFF",
      "bounds": [
        0,
        40,
        146,
        56
      ],
      "pageId": 1,
      "controlSetId": 1,
      "inputs": [
        {
          "potId": 1,
          "valueId": "value"
        }
      ],
      "values": [
        {
          "min": 0,
          "max": 127,
          "defaultValue": 63,
          "message": {
            "type": "cc7",
            "parameterNumber": 10,
            "min": 0,
            "max": 127,
            "deviceId": 1
          },
          "id": "value"
        }
      ]
    }
  ]
}

Looks like there must be a bug (or syntax change) Martin in firmware 1.3.1, as I loaded up the Alpha Juno MKS50 preset you made, and it wasn’t updating patches either when a few weeks ago it was.

I still had the firmware 1.1.6 file on my computer, and after loading that, the Alpha Juno preset was updating patches from the Alpha Juno perfectly.

Firmware v1.3.2 is just out and fixes that issue, among others.

I wonder why "type": "cc7" is needed here and whether it can be omitted. As I understand it, specifying cc7 isn’t causing the device to transform the value in any way – it just merely assigns it to parameter #2 which happens to be a CC. What do I miss?

Thanks. I see your point, I’m not sure sure however if in your example this is correct:

My understanding is that id would have to be 10 in this case too, i.e. that id always refers to the parameterNumber of the control. I’ll have to test your example though to confirm.