Parameter Number (ID) changes SysEx values

[HaPe]

Seems like it’s not really my E1 day today, sorry…

I tried to continue working on my Preset as I stumbled over another issue. There is a not really reproducible relation between the Parameter No. and the SysEx data that should be sent.

I have set up a SysEx command which always stays the same but the output changes when the Parameter No. changes. Sometimes even the length of the SysEx command changes.

I shoot a screencast which shows the behaviour. I am using the dedicated controller that is highlighted in the editor on the E1 and a MIDI Monitor shows the output. First the working example on the “Resonance” controller, then the other that behaves kind of weird.

Is this a bug or am I missing something? BTW: I read about that in some cases I need to implement the Parameter numbers into the JSON data which from my experience applies to commands containing two value bytes. These smaller commands doesn’t contain the Parameter No. in their JSON data.

Thanks.

[Flyweight]

@HaPe

t a screencast which shows the behaviour. I am using the dedicated controller that is highlighted in the editor on the E1 and a MIDI Monitor shows the output. First the working example on the “Resonance” controller, then the other that behaves kind of weird.

Yes Parameter number is not required with single byte values.
Maybe look at the raw json.
Can you share the preset?

Why are you selecting the parameter number in the left pane? Doesn’t that imply changing the parameter number of the current selected control?
Shouldn’t you just click on the parameter you want to change?

What are you monitoring actually? what program is that?
I am on windows so cannot monitor and edit unless using a midiloopback …

[HaPe]

Thanks @Flyweight , …

@Flyweight

Can you share the preset?

… I can if you think it will help.

MONTAGE EDP Elements.epr.zip

@Flyweight

Why are you selecting the parameter number in the left pane?

From what I read and learned through my experiences so far is that a parameter number should be unique and every control needs to have a dedicated one. If you have two controls using the same parameter number they work simultaneously when one is moved. At least in my case, please correct me if I got or’m doing something wrong.

So I decided to give each control a unique parameter number in a preset, starting from 1 to … whatever.

@Flyweight

Shouldn’t you just click on the parameter you want to change?

I have setup this particular control with the correct SysEx message for my destination parameter on the instrument like I did a hundred times before in other presets. In most cases I work with copies to use the existing SysEx command and just change the few bytes that need to be changed to a new parameter destination. After that I assign a different parameter number so that it works independently. That used to work before as I created my other presets on previous firmware versions.

As you can see in the video, the output of the SysEx command changes just when I change the parameter number. And just a few parameter numbers seem to let the original SysEx data output untouched so that the control works with the parameter destination. And remember: just the output changes. The data in the JSON view always stays the same like shown in the screenshot above the MIDI Monitor display.

@Flyweight

What are you monitoring actually? what program is that?

I am monitoring simply the output of Electra One with a very helpful MIDI Monitor (Mac only). I can’t imagine living without such a tool because it just saves tons of time for issues like this.

We probably have to wait until Martin shares his thoughts on this topic.

[Flyweight]

I think the issue is this:

            "data": [
              "F0",
              "43",
              "10",
              "7F",
              "1C",
              "02",
              "42",
              "00",
              "01",
              {
                "type": "value",
                "rules": [
                  {
                    "type": "sysex",
                    "parameterNumber": 2,
                    "parameterBitPosition": 7,
                    "byteBitPosition": 0,
                    "bitWidth": 7
                  }
                ]
              },
              {
                "type": "value",
                "rules": [
                  {
                    "type": "sysex",
                    "parameterNumber": 2,
                    "parameterBitPosition": 0,
                    "byteBitPosition": 0,
                    "bitWidth": 7
                  }
                ]
              },
              "F7"

I do not see any weird behavior of the parameters.
So probably this 2 byte values need to be corrected.
Curious what Martin will say.

Edit: I loaded the templated and compared the json with what i seen in the midi monitor.
All the send out sysex strings look good.
But I also just updated to v3.1 so who knows.

[martin]

@HaPe

… I can if you think it will help.

Sharing a preset when reporting an issue is always handy. It is easier to reproduce then.

I just tested that and I cannot reproduce that yet. I was observing the output on the USB device port though. It works as expected. I can see that your MIDI Monitor monitors “To Montage”. Can you check output on Electra Controller Port 1, like this:

When you do this, do you see the same issue?

@HaPe

From what I read and learned through my experiences so far is that a parameter number should be unique and every control needs to have a dedicated one. If you have two controls using the same parameter number they work simultaneously when one is moved. At least in my case, please correct me if I got or’m doing something wrong.

So I decided to give each control a unique parameter number in a preset, starting from 1 to … whatever.

yes, that is correct. Just one small correction. The parameter number should be unique per message type. ie. sysex parameter number 1 and cc parameter number 1 are considered to be two different parameters.

@HaPe

I am monitoring simply the output of Electra One with a very helpful MIDI Monitor (Mac only). I can’t imagine living without such a tool because it just saves tons of time for issues like this.

Do you see the same data when you use the MIDI console in the webapp?

[HaPe]

Thanks a lot Martin!

@martin

When you do this, do you see the same issue?

It looks like. As I wrote (also important for @Flyweight) I always worked with the highlighted control “LFO SPEED”. As follows the MIDI output with one of the “working” parameter numbers …

… and one with the parameter number I initially tried and stumbled over this issue.

The inserted screenshot on the right hand side shows what should have been sent.

@martin

Do you see the same data when you use the MIDI console in the webapp?

Yes, it shows the same wrong values…

Thanks again.

[martin]

Check, I was able to reproduce it with using the exact parameter numbers you just sent. I will look at that today.

[Flyweight]

Strangely I am not able to reproduce.

Using your template:

Creating a new template with the same sysex and default value.

Uploading: image.png… … hmm something went wrong…image lost

I am on windows: chrome: Version 109.0.5414.120 (Official Build) (64-bit) for what its worth.

[HaPe]

@martin Thanks so much!

[HaPe]

@Flyweight thanks a lot for your help. Luckily Martin was able to reproduce it. We will see. I’m just happy that the issue (at least in this particular case) wasn’t sitting in front of the screen.

[martin]

@hape I am looking at the issue and I just noticed that the preset has controls with the same ids on different pages. In that specific example you sent, the sysex control with parameter number 3 is located on the second page.

The trouble is that in such situation - when parameter number is the same but other message bytes differ - E1 sends out the first message linked to that parameter. I will still research it more, I just wanted to share what I found so far.

I will also think about how to display the parameters on some overview that would allow to detect this easily. For now, pressing a space bar will show such information for current page.

[HaPe]

Hi @martin, thanks so much for sharing this information.

I was further developing my pages today to cover more Elements on the next pages with the same parameters. As I moved forward with higher (and of course unused) parameter ID’s I never had any issue. I was about to share this experience with you within the next minutes but you were quicker.

I just got back to page 1 and tried the parameter ID’s that didn’t work yesterday and now they work because I deleted the previously kind of “left over” controls on the next pages. So I can confirm that it works now at least after just two tests but I am sure that was the reason. Apologies for that but I wasn’t aware of this and by far not able to get to this solution. I was thinking of a kind of cache that maybe stores used parameter ID’s and wasn’t cleared after I thought I deleted all controls with the same ID’s. But during my issues I just focussed on my page 1 and forgot about the others on the next pages.

During my intensive work today I always stumbled over the fact that not all default values were being set correctly after updating the layout to E1 as mentioned in the other post here…

https://forum.electra.one/t/default-values-not-being-sent-from-editor

I wonder if there is a workaround i.e. to place one control button on the E1 page that calls up all default values on this particular page.

Since you mentioned today the differences in the display hardware on different unit series I also wonder if the touch sensitivity of the display has been changed with one of the recent firmware updates. Since I needed to double tap a lot today to check my work I have the feeling that it is harder to set the defaults using a double tap than it was before. Is that possible?